Refactor avoidCapture function

[fisker]

Reason behind this change, the new version of ESLint allows ecmaVersion: "latest", and this part don't understand it.

Let's not care about ecmaVersion and strict mode, just use the safest strategy.

WDYT? @futpib

[fisker]

On second thought, it's not safe anyway, running ESLint with specific ecma version, doesn't mean scripts always run on the same environment. I always use my shared config with ecmaVersion: 2021, but my code can run on old engine.

[futpib]

My implementation tried to match the target ecma version closely with regards to reserved words and allowed arguments as a variable name where language allows it without shadowing. This rewrite bans reserved words regardless of ecma version and bans arguments name ignoring complex rules around it.

If original approach is not a valuable enough feature, this PR provides a more practical approach that will be easier to maintain and should be merged. Yet it seems original code could have been fixed to support 'latest' ecma version with a one line patch.

[fisker]

I also found potential threat, for example we used it in catch-error-name, if some bad shared config, config it as

"unicorn/catch-error-name": [
	"error",
	{
		"name": "){} evilCode; if(false"
	}
]

try {} catch (e) {}

will fix to

try {} catch (){} evilCode; if(false) {}

And it may run into infinity loop in all used rules,

for example:

"unicorn/prevent-abbreviations": [
	"error",
	{
		"replacements":  {
			"a" : {
				123: true
			}
		}
	}
]

current implementation will not find a usable variable name and hang forever, I'll fix.

[sindresorhus]

I also found potential threat, for example we used it in catch-error-name, if some bad shared config, config it as

I wouldn't consider that a vulnerability. It applies to a lot of ESLint rules. Rules make no guarantee about being resistant to evil config, nor should they.

[fisker]

But the infinity one, people may config it by mistake, for example, added a space after the replacement.

[sindresorhus]

The infinity case I agree we should fix.