Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Change Request: Migrate the ESLint repository to ESM
See original GitHub issueESLint version
v8.8.0
What problem do you want to solve?
Currently, the ESLint codebase uses CommonJS require()s.
What do you think is the correct solution?
We’d like to migrate the repository to use ES Modules.
Participation
- I am willing to submit a pull request for this change.
Additional comments
We added this to the roadmap in the 2022-01-27 TSC meeting.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:25
- Comments:22 (15 by maintainers)
Top Results From Across the Web
ESLint Rules for Migrating Projects from CommonJS to ESM
Rules that can be helpful for anyone who wants to migrate a project from CommonJS to ESM now: eslint-plugin-node, eslint-plugin-import, ...
Read more >Configuration Files - ESLint - Pluggable JavaScript Linter
A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript. Maintain your code quality with ease.
Read more >eslint-import-resolver-typescript - npm
Start using eslint-import-resolver-typescript in your project by running `npm i eslint-import-resolver-typescript`.
Read more >Instead change the require of index.js, to a dynamic import ...
It is because of the node-fetch package. As recent versions of this package only support ESM, you have to downgrade it to an...
Read more >Upgrade your Node app: From CommonJS to ES Modules
1) Prepare your code · 2) Update the package.json · 3) Convert all imports and exports · 4) Fix imports and exports ·...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Please do not go ESM-only; that will be a huge burden on the ecosystem. As a maintainer of the most popular shared config and three of the most used plugins, I can’t guarantee it will be feasible to maintain any of them with eslint being ESM-only. To be quite frank, it would be an unmitigated disaster.
Literally the only advantage to going ESM-only I’m aware of is top-level await, and the only part of a program that would truly ever need that is a CLI entry point.
If it helps, pick literally any sindre module that’s migrated to ESM-only, and click the “versions” tab on its npm package page. You’ll see - even on the packages that made the switch over a year ago - that virtually nobody is using the ESM-only versions. That’s because they, or their intermediary dependents, can’t upgrade to it.
I believe the main reason why the ecosystem hasn’t fully moved to esm yet is because JS tooling hasn’t allowed it to do so. Once ESLint and Babel add support for esm, I reckon a lot of us will switch in a heartbeat.