-
Notifications
You must be signed in to change notification settings - Fork 28.2k
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
Bare specifiers definition. #53022
Comments
Would you like to open a PR to add your proposed changes? |
I don't know if your example shows that the sentence is incorrect. It would be incorrect if you were able to show an example of a package with an |
From the docs: "Including the file extension is only necessary for packages without an "exports" field." The package in my example does not have an "exports" field and yet it is not necessary to include the file extension to load it. It's as simple as that. |
I don’t see a contradiction, but I’m not a native speaker so maybe there’s some nuance I’m missing. That being said, if someone suggests a better wording, it would likely gets accepted. |
I don't understand what you're saying. I didn't suggest anything. I pointed at a false assertion, no more, no less. |
I didn’t say you suggested anything.
Are you saying that “only necessary” and “always necessary” mean the same thing? I’m not trying to sound dismissive, I’m only trying to express my interpretation of the docs you cited. |
I believe @gitspeaks is suggesting that according to the documentation, you must specify the full file path (with extension) when the package doesn't export anything with But, in my opinion, @gitspeaks is misunderstanding the documentation. IIUC It is referring to getting a module by its path, and not by its module name (E.G
In your example, you are getting the main entry point. Do you also not require an extension when getting a feature module? |
In this context, I don't see a reasonable interpretation otherwise. Quote: "Including the file extension is only necessary for packages without an 'exports' field."
In other words, the sentence says nothing! Does that seem reasonable to you? @RedYetiDev I understand the documentation completely. Here is the example adjusted to show a bare specifier that includes a file extension. Note that the module does not include an 'exports' key. However, all this is irrelevant to the point I'm making. index.mjs
node_modules/mymodule/index.mjs
node_modules/mymodule/package.json
Hello from module! |
And if you remove the extension? (Also, if this is irrelevant, than I don't think I am understanding the statement you're making) |
Of course it won't work, the module does not have an export field.
Read: "Including the file extension is only necessary for packages without an 'exports' field or a 'main' field." Does this help? |
Now, you might ask yourself why I didn't just state: Including the file extension is only necessary for packages without an 'exports' field or a 'main' field from the very beginning. The answer is simple: I don't know if including the file extension is only necessary for packages without an 'exports' field or a 'main' field, or if there are other exceptions. |
If you ask yourself "is it necessary to include the file extension?", the docs responds "only for packages without an
That would be incorrect, you still need to include the file extension (e.g. try to load |
I’m sorry, but I’m still not understanding the issue here, I think the docs are correct (as @aduh95 has said) |
To sum-up:
|
So, a change like this would be what you find sutable? Or maybe a removal of the note at the end? Original:
Changed:
|
If the goal of the 'note at the end' was to simply say that the bare specifier of a 'feature module' is the file name of the feature module prefixed by the package name, then of course I would delete the mention of the 'exports' field of a package, as it is simply irrelevant. I would just write: Bare specifiers are module identifiers like 'some-package' or 'some-package/shuffle'. These specifiers can point to the main entry point of a package by using just the package name or to a specific feature module within a package by prefixing the package name to the feature module file name like 'some-package/some-feature.mjs'. |
edit: "some-package/some-feature.mjs" |
@aduh95 would this wording work? (with any slight adjustments that would need to be made) |
I disagree. "feature-module file path" can be confused with the file's file-system path. Just add another example with a deeper path: "Bare specifiers are module identifiers like 'some-package' or 'some-package/shuffle'. These specifiers can point to the main entry point of a package by using just the package name or to a specific feature module within a package by prefixing the package name to the feature module file name like 'some-package/some-feature.mjs' or 'some-package/some-submodule/some-feature.mjs." |
|
I suggest: "Bare specifiers are module identifiers like |
This might be redundant, but I'd like for @nodejs/loaders to weigh in on this "issue" in general, that group (including @aduh95) are the final judges, not me. |
Alternatively: "Bare specifiers are module identifiers like |
Including Exported Feature Module Paths: "Bare specifiers are module identifiers like |
Affected URL(s)
https://nodejs.org/docs/latest-v20.x/api/esm.html#terminology
Description of the problem
"Bare specifiers like 'some-package' or 'some-package/shuffle'. They can refer to the main entry point of a package by the package name, or a specific feature module within a package prefixed by the package name as per the examples respectively. Including the file extension is only necessary for packages without an "exports" field."
Incorrect, including the file extension in bare specifiers is not necessary for packages with "main" field.
Example:
index.mjs
:node_modules/mymodule/index.mjs
:node_modules/mymodule/package.json
:Hello from module!
The text was updated successfully, but these errors were encountered: