Fix browserslist support, added options to disable browserlist feature

[latel]

New features:

• bumping up minor version for a new but compatible option

• new option to disable browserslist support(to enforce no usages even though browsers are supported)

  rules: {
    'no-lookahead-lookbehind-regexp/no-lookahead-lookbehind-regexp': [
      'error',
      'no-lookahead',
   + { browserslist: false }
   ],
  }
  

Fixed:

• fix browserslist feature, eg: currently plugin will report lookahead errors even though lookahead is supported
  
  
  

Breaking Changes: none

[JonasBa]

@latel instead of adding a new option, can we just check for browserslist config and enable it only if it is present?

[latel]

@latel instead of adding a new option, can we just check for browserslist config and enable it only if it is present?

check for browserslist config and enable it only if it is present may not be a good idea, because too many toolchains like postcss and eslint-plugin-compat relies on it. we currently want an option to disable our plugin's browserslist support itself, at the same time, keep related toolchains works as well.

[JonasBa]

@latel Ok, makes sense. The reasoning makes sense, the only thing I dislike about the PR is that it will require us to bump the package major version as the config has changed - this is something I would like to avoid. I propose that instead of breaking the config options and having to increment the package major, we allow users to pass an options object - since all other values are string types, we can type guard for {browserslist: true/false}. This will mean more work in the package, but we do not break compatibility.

The API would then look something like

'no-lookahead-lookbehind-regexp/no-lookahead-lookbehind-regexp': [
      'error',
      'no-lookbehind',
      'no-negative-lookbehind',
+     {browserslist: false}
   ],

The code in our plugin then checks for object shape and browserslist property and sets it to that value. I think this is more DX friendly and can ship as a minor version change so everyone can seamlessly upgrade.

Mea culpa on the initial API design... it probably should always have been an object.

Let me know if you have any thoughts on this.

P.S. if you do not have time to make this change it's totally understandable and I am happy to take over, just let me know, your contributions are much appreciated!

[latel]

You are right, let's keep options compatible, your suggestions are always welcome

[JonasBa]

👌🏼, thank you for the contribution. I will publish a new version today!

[JonasBa]

Thank you for also fixing my typos :)

[JonasBa]

I think this PR broke some functionality around negative lookbehind, I also just noticed that we copy the string literal for each node value which is not desirable as it can slowdown the plugin and increase memory usage

[latel]

Do you have an actual broken case, let me digest it.

[JonasBa]

Already fixed it, tldr, this was not reporting errors

[latel]

This breaks the main fix in my PR, here is how to re-produce the case.

.eslintrc.js

module.exports = {
  env: {
    browser: true
  },
  extends: [
    'plugin:no-lookahead-lookbehind-regexp/recommended',
  ],
  rules: {
    'no-lookahead-lookbehind-regexp/no-lookahead-lookbehind-regexp': ['error', {
      browserslist: true
    }
    ],
  },
}

.browserslistrc

iOS >= 16.3

src/index.js

const behind = /aaa(?<=1)aaa/
const behindNegative = /bbb(?<!1)bbb/
const ahead = /ccc(?=1)ccc/
const aheadNegative = /ddd(?!1)ddd/
console.log(behind, behindNegative, ahead, aheadNegative)

running ./node_modules/.bin/eslint -c .eslintrc.js --debug src/index.js result in reporting following.

/Volumes/Code/play/webpack/src/index.js
  1:16  error  iOS Safari 16.3: unsupported lookbehind match group at position 3           no-lookahead-lookbehind-regexp/no-lookahead-lookbehind-regexp
  2:24  error  iOS Safari 16.3: unsupported negative lookbehind match group at position 3  no-lookahead-lookbehind-regexp/no-lookahead-lookbehind-regexp
  3:15  error  iOS Safari 16.3: unsupported lookahead match group at position 3            no-lookahead-lookbehind-regexp/no-lookahead-lookbehind-regexp
  4:23  error  iOS Safari 16.3: unsupported negative lookahead match group at position 3   no-lookahead-lookbehind-regexp/no-lookahead-lookbehind-regexp
  5:58  error  Newline required at end of file but not found

In fact, iOS 16.3 and above do support regex lookahead expression,
the plugin's depency caniuse-lite actually do not have a lookahead record, thus we should treat lookahead as always supported when the plugin's config.browserslist is set to true(default value)

[latel]

😢

[JonasBa]

@latel sorry I was off end of last week. Will look into this and fix it

[JonasBa]

Ok, understood. I think this worked before because you were escaping the lookahead from being reported entirely, which should be a configurable option. I will look into it and make sure we have a fix asap

[JonasBa]

@latel would you mind reviewing #6, I added the tests and I think it now works as expected, but a second pair of eyes would help.

Thanks for your patience!

[JonasBa]

ping @latel if you have a moment to review