Skip to content
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

Closed
thernstig opened this issue May 5, 2021 · 6 comments

Comments

@thernstig
Copy link

From https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/extensions.md

For example the node resolver can resolve ./foo/bar to the absolute path /User/someone/foo/bar.js because the .js extension is resolved automatically by default.

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

@ljharb
Copy link
Member

ljharb commented May 5, 2021

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.

@thernstig
Copy link
Author

thernstig commented May 5, 2021

@ljharb thanks, that makes sense. How come you say "shouldn't really be used yet anyways"? We converted our codebase to ESM and use --experimental-specifier-resolution=node to get around not having to add .js to all files, and it works good for us.

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.

@ljharb
Copy link
Member

ljharb commented May 5, 2021

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.

@thernstig
Copy link
Author

thernstig commented May 5, 2021

The experimental flag is likely to go away, and unlikely to ever become default.

Meaning that we will be forced to use .js on files? I think If I recall correctly I saw some posts by you saying that forcing .js on imports is a bad choice, and since you are indeed an authority in the Node ecosystem I listen with big ears 😄

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.

@ljharb
Copy link
Member

ljharb commented May 5, 2021

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.

@thernstig
Copy link
Author

thernstig commented May 6, 2021

Closing this then for now. I alsoa ppreciate very much you spent valuable time giving answers to me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants