-
Notifications
You must be signed in to change notification settings - Fork 127
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
Is ESM supposed to only work with file:// URLs #1423
Comments
I feel obligated to make a clarification regarding the title of the issue: ESM is supposed to work with any URL – you can host modules from custom protocol if you so wish. When loading an ESM file, Node.js assigns it a |
I was asking @mcollina about this on Slack, trying to clarify the question(s) being asked, and in discussion I think we boiled it down to this:
|
For added context, |
I don't think having file paths and URLs are exclusive, I can see cases where people would want paths and cases people would want URLs depending on what they're building with Node.js If we add So for me:
Generally I prefer Node.js not dictate stuff down to the ecosystem rather than listen to what people in the ecosystem are asking for and making them more productive - so from that point of view I'm on the "yield" side (though it's more "listen" than "yield"). |
To answer my own question, I think I’d like to make it easier to work with both path strings and URL strings in ESM. Yes we should add I see @aduh95’s point that URL strings (or |
Ecosystems can’t be forced to change; anything that requires it for ESM makes adoption harder. Migration is achieved by preserving existing patterns and also providing a preferred (by the authors) pattern that’s considered better by the ecosystem (not by the authors). |
I know issue is in the TSC, but as possibly one of the biggest ESM cheerleaders (and one who has dropped a block on related issues/PRs), I'm very much in favour of easing adoption (in appropriate ways). This is something I myself found wanting in days of yore. That IF it's truly needed nowadays and Apologies for the intrusion. /exit |
That's not my point nor my opinion, I don't think one is better than the other. A CJS module has a 1-to-1 relationship with a path (and it's easy to expose it via |
I think the determination that ESM works with URLs and not paths is only correct from the point of view of the implementation/the spec.
I think an ES module has a 1-to-1 relationship with a specifier, which is not necessarily a URL, right? why is it incorrect for node to expose |
@MoLow in the case of // let's assume import.meta.url === 'file:///root/entry.js'
import "./dir%20name/index.js"; // loads '/root/dir name/index.js'
import "./dir%2520name/index.js"; // loads '/root/dir%20name/index.js'
import "./dir%name/index.js"; // throws
That's not correct, a ES module has a unique URL, and a URL can reference at most one1 ES module. Several specifiers can be resolved to the same URL, or the same specifier can be resolved to multiple URLs, there's no 1-to-1 relationship with specifiers. // import.meta.url === 'file:///root/a.js'
import "./b.js"; // references file:///root/b.js // import.meta.url === 'file:///root/subdir/a.js'
import '../b.js'; // also references file:///root/b.js
import './b.js'; // references file:///root/subdir/b.js In the above example, the same specifier
Specifiers are never paths. Using a POSIX path as a specifier may or may not load the correct file, or can throw. Footnotes
|
Don't forget Node also supports modules loaded from |
@JakobJingleheimer meant to comment earlier but forgot - I don't speak for the TSC and I'm a very new member - but something being in the TSC repo or anywhere else does not mean it's only for the TSC to discuss and feedback/opinions/ideas are always welcome and appreciated. |
If that is the case, then... I'm all for following specs. I'm really quite a pedant about it 99.9999% of the time. However, we are talking about a runtime/framework designed for running JavaScript code as a system application. As such, I expect to be able to work with the filesystem within my scripts without having to jump through translation layers, i.e. URLs. If it is determined that ESM scripts should only use URLs then consider this user as one that will completely write off ESM as not useful in his work and will stick with CJS. |
As part of nodejs/node#48740 and our recent survey, quite a few people asked for having easy access to
__filename
and__dirname
inside ESM.Right now to get those values, users have to do a bit of additional work:
Note that
import.meta.url
is a string starting withfile://
, andfile://
URLs are not standardized in any way.After much discussion in the meeting, the distilled version of the question comes into forms:
file://{path}
stringsI don't think both are exclusive. They are just two separate use cases and only catering for one is problematic.
I hope we can reach a consensus on this, so we can use it to drive further decisions.
The text was updated successfully, but these errors were encountered: