Pelle Wessman

I was working on a command line version of that here: https://github.com/voxpelli/compare-eslint-configs Still planning to update it to ESLint 9 and flat configs: https://github.com/voxpelli/compare-eslint-configs/issues/46

@filipw01 Its not immediately obvious to me what the improvements are, and my experience with these helpers has been that they easily turn into a game of whackamole – any...

#975 is also touching some of these files. I will not have time to review either, just noting it

I would suggest that you move to https://github.com/neostandard/neostandard and use the `semi: true` option there, then you will have an up to date setup that needs no custom rule definitions

Because it’s the only standardized place for engine support information and the only place where you can programmatically check the engine support ranges of your dependencies, as I also demonstrate...

If that’s a concern then one could start out with doing `>=20`, as that at least shows that everything below 20 is unsupported, and it avoids any granular promises

Some thoughts on this from another part of the ecosystem: https://github.com/pillarjs/finalhandler/pull/59 (Found through @wesleytodd’s Twitter https://x.com/wesleytodd/status/1831699618964631653)

> Because no package manager does anything with the field except to write a warning log to stdout Maybe its not the package managers task to check the field? One...

> In my view, it is a completely pointless field which only adds maintenance and support burden. Even when set to `>=20`? It doesn't have to be changed until it's...

I use it to automate detection of dependencies that has a narrower engine support than what my own package has – checking that manually requires either excellent changelogs or manual...