Enzyme: Attribute selector values containing # broke in 2.4.0

[rixth]

https://github.com/airbnb/enzyme/issues/314 caused a regression. It broke attribute selectors with values containing #, ex a[href='/page#anchor'].

Failing test case:

it('should query attributes with hashes in their values', () => {
  const wrapper = mount(
    <div>
      <a href="/page">Hello</a>
      <a href="/page#anchor">World</a>
    </div>
  );
  expect(wrapper.find("a[href='/page#anchor']")).to.have.length(1);
});

[rixth]

In the function splitSelector in Utils.js, the regular expression /(?=\.|\[.*\])|(?=#|\[#.*\])/ is a little over-zealous.

Input: a[href='/page#anchor']
Output before change: [ 'a', '[href=\'/page#anchor\']' ]
Output after change:  [ 'a', '[href=\'/page', '#anchor\']' ]

[aweary]

Well, it's not necessary over-zealous, it's just not smart enough to handle compound selectors and attribute values containing #. https://github.com/airbnb/enzyme/pull/458 would likely fix this, but feel free to work on a PR to fix the regex for now, since https://github.com/airbnb/enzyme/pull/458 still has issues that haven't been worked out.

[ljharb]

fwiw, before releasing or merging anything new, we urgently need to either fix this behavior regression or revert #314.

[aweary]

Reverting https://github.com/airbnb/enzyme/pull/387 would be easiest if we need an urgent fix, I'm not 100% sure how difficult it's going to be to get this behavior working correctly. That regex is getting unwieldy

[aweary]

@ljharb should we just revert #387? It seems that fixing this behavior is going to be non-trivial, and we've already let this sit for quite a while.

[ljharb]

Yes, I think we should.

[ljharb]

Let's keep the test cases tho, skipped.

[mik01aj]

Maybe #547 is related to this too?

[rixth]

@mik01aj I don't think so -- the code that caused this bug was not present in 2.3.0 (as mentioned in the linked ticket). It's possible it's still this regex that's "responsible", though.

[rixth]

Why was 2.5.0+ released given that it was a regression, and there was earlier talk of reverting the PR that introduced it?

[ljharb]

I think this has slipped through the cracks. When we get a fix in, I'll backport it to both the 2.4.x and 2.5.x lines.

[ljharb]

I've put up #670 which fixes this issue without reverting #387.

[ljharb]

v2.4.2, v2.5.2, and v2.6.0 are all now published and all contain this fix.

Sorry for the delay!