-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docs: import/extensions says node resolver resolves file extensions automatically #2043
Comments
It’s true for CJS (or ESM transpiled to CJS), which is the only resolution we deal with currently. That link references node’s native ESM, which isn’t supported here yet and shouldn’t really be used yet anyways. |
@ljharb thanks, that makes sense. How come you say "shouldn't really be used yet anyways"? We converted our codebase to ESM and use But the biggest concern is that some packages will require ESM to be upgraded soon. See for example https://github.com/chalk/strip-ansi/releases/tag/v7.0.0 (77 million weekly downloads) and his reasoning https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c - this means we cannot upgrade many of the packages he uses, which is needed at times to get security fixes. So not using ESM is starting to become "not an option" if you want to stay on the latest and greatest. |
The experimental flag is likely to go away, and unlikely to ever become default. Separately, the ecosystem and tooling around native ESM is nowhere near production-ready. Packages that force consumers to use ESM will simply lose users, no matter how prolific the author is. |
Meaning that we will be forced to use edit: Oh and on the topic of this thread, I am fine with closing it if you believe the docs should not be updated to mention anything about ESM and extensions when using that. |
Yes, I think it is a terrible choice, and I would have preferred that that resolution behavior be the default. However, I don't make the decisions, and that doesn't look likely. The "exports" field, at least, relieves package consumers from having to use extensions, but, relative native ESM imports will have to use them, unfortunately. Either way, until the ecosystem - and every commonly used tool - is fully updated to handle native ESM, I think it's too premature for anyone to be using. |
Closing this then for now. I alsoa ppreciate very much you spent valuable time giving answers to me! |
From https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/extensions.md
Is this true? Node.js requires the extension on files for relative paths: https://nodejs.org/docs/latest-v14.x/api/esm.html#esm_mandatory_file_extensions
The text was updated successfully, but these errors were encountered: