What breaking changes should be included in the next major version (v5) release? #235
Comments
I don't see quite benefits to become ESM only for a widely used ESLint plugin at this time
I forget to suggest use extra I don't know whether would it be possible to support it without breaking changes
Great to replace I'll investigate |
The idea is that the major version bump is already coming, and we might just migrate to ESM-only considering that Node.js 20+ supports Also, @43081j can help us investigate and migrate to ESM-only.
It is already possible with interface v3, see this example: // eslint.config.js
'import-x-/resolver': [
createXResolver({} /** options */)
]
// resolver.js
export function createXResolver(options) {
// I can do something with options here
const reusableInstance = new Factory(options);
return {
interfaceVersion: 3,
name: 'x',
resolve(src, mod) {
// I can still access options even down here
reusableInstance.method(src, mod, options);
}
}
}Basically, you can access options anywhere in the scope, including the resolve function.
|
I understand the we want ESM eventually, but as a downstream plugin for ESLint, I would recommend follow ESLint's strategy unless there are huge features we must implement in ESM, otherwise cjs consumers are blocked without any benefits
What I'm linking is not about resolver's options but import plugin's running context,
Yes, should we enter https://github.com/changesets/changesets/blob/main/docs/prereleases.md#prereleases |
What strategy is that? All plugins are loaded by a dynamic import inside eslint, relying on node to deal with cjs interop. Moving to esm would mean you can't use this plugin in a cjs config file before node 20 basically, but nothing else would change. If we come back in a year, I suspect you'll be given the same decision to make. There will always be someone with an old cjs config somewhere |
I personally would prefer following https://github.com/eslint/eslint/blob/c99db89141f1601abe6f9d398a4b6c126e3a0bdb/package.json#L6 and https://github.com/eslint/eslint/blob/c99db89141f1601abe6f9d398a4b6c126e3a0bdb/package.json#L223 or dual packaging for now. But we can made a prototype to seem if we migrate to ESM only, how much would the size be reduced, say we have And also we should do some analysis on our dependents. |
|
The engine constraint isn't affected. You can continue to use node 18 if this goes esm only It just means your config should be esm too eslint can't really be compared to the plugins either. It'll be commonjs for much longer than plugins are because it's a much bigger job to rework it into esm We certainly shouldn't move to a dual package in any situation. Either we should stick with cjs and move to esm later, or move to esm now. One way or another, the move would happen and before eslint itself moves |
|
Just check some dependents randomly, almost all of them are using ESM config file, so let's go for ESM only. 🍻 |
Node.js 20+ has |
|
That's true. Seems we're all in agreement 🥳 It is scary times making such a big decision but I think we can set a good example here for others to follow. If we can figure it out, it'd be really great |
But if we don't raise the engine constraints, we will have to write a detailed docs explaining:
If we raise the engine constraints to 20+, then there will be no changes needed toward @JounQin @43081j So what do you think, should we raise the engine constraints or not? |
|
No need to raise to 20+, |
|
I think as long as we document that you should use an mjs config in We may not need to document the fact you can require/import it in 20+ since they shouldn't need to care (as it'll work as is) |
|
I'd like to change this repo a mono repo by adding a new package like |
Sure! And let's use the turborepo. |
|
I'm not familiar with turborepo, contributing to |
|
if you want something lightweight, i'd use npm workspaces & wireit otherwise i'd probably use nx |
I have used wireit before, worked well as a command runner, not sure if it handles monorepo well. |
|
it was built mostly with monorepos in mind, that's pretty much what it was originally for combined with npm workspaces, it works well |
|
I just remember I wanted to support resolving two files, one for js source, one for flow/ts definition. But on the other hand, Node 23+ supports stripping types by default, I don't how many adapters would ship ts source directly. Anyway, I think resolving two files would be helpful for near future. @SukkaW Thoughts? |
Hmmm. I don't see reasons for that. Publishing source code to the npm registry is a stupid idea anyway. Node.js doesn't support full TypeScript syntax other than the erasable syntax. And no one, not even Bun, supports running Flow directly. Not mentioning there are still coffeescript (and many more variants) out there in the fields. On the other hand, the type definitions should be aligned with the JS module files' exports anyway. And if it is not, it is the authors of those packages' fault, not ours. So technically we only need to resolve either type definitions or JS module files, and we should prefer type definitions for type imports. |
|
@SukkaW Oh, I'm not saying true source codes but the entry point in
|
That's why we have And although Any other examples? |
|
Yes, But // https://app.unpkg.com/[email protected]/files/package.json
"./action": {
"types": "./types/index.d.ts"
},
"./animate": {
"types": "./types/index.d.ts",
"default": "./src/animate/index.js"
},
"./compiler": {
"types": "./types/index.d.ts",
"require": "./compiler/index.js",
"default": "./src/compiler/index.js"
},
"./easing": {
"types": "./types/index.d.ts",
"default": "./src/easing/index.js"
},Since we are implementing new resolvers that support |
|
@SukkaW The |
Hmmmm, for this specific typescript case, we might be able to workaround this with |
@SukkaW You mean resolving an absolute path with a query? But the query itself can be real path. I remembered
Not sure I follow, for pure JavaScript modules, there should be only such issues. But |
Uh oh!
There was an error while loading. Please reload this page.
Drop Node.js 18 supportsWe will keep Node.js 18 supports, but the plugin will go ESM-onlyThis allowseslint-plugin-import-xto become ESM-onlyIf we only target Node.js 20+, thenrequire(ESM)will be available ineslint.config.cjs.require('eslint-plugin-import-x')w/o changesimportandeslint.config.mjs, but the rest of your app can remain CommonJS only.import-x/resolverimport-x/resolver-legacyoptions (which will be removed in v6 I guess?).eslint-import-resolver-nodewith our built-in Replacing the built-in default import resolver that supportsexportsandimportsfrompackage.json#208 feat: implement a resolver that supportsexports#209importsandexportsmaps. This is because ljharb refuses to implement such features ineslint-import-resolver-nodeand even locks the related issue.fixoption by defaultextensionsrule, related feat(extensions): supportpathGroupOverridesandfixoptions #327 and feat: add suggestions support forextensionsunexpectedcase #329The text was updated successfully, but these errors were encountered: