RFC: ceasing maintenance

[robatwilliams]

Is this tool necessary anymore?

I'm aware that the latest build tools / frameworks (e.g. Vite, Angular) have built-in capability to target a browsers specified via a browserslist. It appears to me that the remaining use cases are a) projects not using a transpiler, and b) projects using older tooling.

I have little visibility of if people are still choosing to start using this, or if all the downloads are from existing installations.

[helvenk]

Thank you for your great work. I've just started using this tool.

Modern build tools can indeed transpile code based on browserlist configuration and automatically include polyfills. Therefore, for new projects, this seems unnecessary.

For me, my use case involves checking whether our code supports a specific version of a browser, such as Android 7. This doesn't necessarily mean we need to target that version specifically; I just want to understand the compatibility.

In that case I think it would be necessary.

Additionally, when I ran npx check-es-compat ., it didn't work. It gave me the error: "Failed to load plugin 'ecmascript-compat' declared in 'BaseConfig': This method cannot be used with flat config."
Could you help me?

[robatwilliams]

The above issue will be due to #92

[helvenk]

The above issue will be due to #92

It works on node 18，but I used it on node 16 before

[replete]

I'll just chip in, the reason I'm interested in using this is to find out compatibility implications during development time when not using frameworks and building things on websites with large audiences and wanting to make informed decisions on compatibility. It's helpful at development time to know what

I recently used https://github.com/anandthakker/doiuse for CSS, which tells me browser version support for specific features I am using and at development time this allowed me to make some tweaks before I built the whole thing and unnecessarily made something that would be broken on 2 year old browsers. Sure, for the majority of cases people have updating devices, but there are always some users stuck on an older handset and being able to instrument your code allows you to make informed decisions about what is worth supporting and what would need to change.

Understandable though not wanting to maintain this if it doesn't benefit you, there's a few of these projects that seem to be dead. I kinda wish MDN just did it themselves, it's definitely very useful if you aren't relying on frameworks. I mean there's probably always going to be compatibility issues with Javascript and older devices.

Thanks for all the work you have done so far

[replete]

FYI stumbled on https://github.com/amilajack/eslint-plugin-compat and going to test it out

[robatwilliams]

Marked both packages as deprecated on NPM.

Added "deprecated" to repo's about.

[daun]

Too bad this is marked as deprecated :( We're great fans of using it in a TypeScript library to check against our browser compatibility targets and publish them in our docs for users loading it from a CDN. It's not mission-critical, but a wonderful tool for that.

[Kristinita]

Type: Reply 💬

Is this tool necessary anymore?

Definitely necessary.

1. Not all projects use frameworks as Vite or Angular. It would be nice if users have the CLI solution independent of environment/frameworks.
2. I don’t know comparable CLI alternative. eslint-plugin-compat check not all cases that es-compat check.

Possibly, I wouldn’t accept the pull request #106 completely due to it contains many changes not related with the migration to the Flat config, but I hope that someday you accept changes that related with the migration.

Thanks.

[anomiex]

If people are looking for a replacement for the eslint plugin, eslint-plugin-es-x has rules and is still maintained. @automattic/eslint-config-target-es uses MDN data to enable rules from that plugin based on a browserslist config.

Eslint with an appropriate config could potentially be used as a CLI solution.