-
Notifications
You must be signed in to change notification settings - Fork 29.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
module: add specific error for dir import #33220
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did not have to wait long for this PR, thank you @aduh95. Just a few comments - let me know if you have any questions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @nodejs/modules-active-members
So … maybe I’m missing something, but I feel like this makes the error message more correct, but not necessarily more helpful. The original situation is one like this: package.json: {
"exports": {
"import": "./bar.mjs"
}
} bar.mjs: export default 42; foo.mjs: import './'; As a user, neither
|
@addaleax with the PR at #31906 landed the error message will look like:
Hopefully that should make this clearer I think. |
@guybedford With this PR, rebased against master, I get the following in the scenario above:
Which is about as helpful as the current message coming from Node.js 14.x. |
@addaleax right, we definitely need the hint as I've explained to be output in this PR. If you have other suggestions please feel free to provide them as well. |
@guybedford I guess my main issue is that neither |
FWIW I agree with @addaleax, I think it would more helpful to have a more specific error. I feel we should also use this opportunity to promote package exports and package self-referencing for people coming from CJS. |
@addaleax thanks for explaining your thoughts here. These are good points! If you don't mind diving in a little.... Ok... so, the current logic is:
The root cause of this issue is thus really the feature added in (2). Based on your feedback, it sounds like the suggested path forward would be to:
Note that neither (1) or (2) directly relate to this PR. But I think that would be the best breadth of solution to property tackle this based on the discussion here. Let me know how that sounds further. |
@guybedford Not sure I’m qualified to speak to a lot here, but 1. sounds good. Lots of people might have the expectation that, since |
@addaleax what do you think we should do for other file descriptors? The same error, module not found, or another one? |
@guybedford I’m not really sure that I understand where file descriptors come into play here, or if you’re using that term to mean something other than system interface file descriptors, what it is that you’re referring to? |
@addaleax just wondering, while we are refining these semantics, if |
@guybedford I think that line should read |
Ok sounds good! Let's do that then and thanks for the feedback here. |
b629609
to
0ef0588
Compare
An issue I have is the $ out/Release/node test/parallel/test-directory-import.js
.../node/test/common/index.js:600
const crashOnUnhandledRejection = (err) => { throw err; };
^
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '.../node/test/fixtures/packages/main' imported from .../node/test/parallel/test-directory-import.js
Did you mean to import .../node/test/fixtures/packages/main/package-main-module.js?
at finalizeResolution (internal/modules/esm/resolve.js:277:11)
at moduleResolve (internal/modules/esm/resolve.js:658:10)
at Loader.defaultResolve [as _resolve] (internal/modules/esm/resolve.js:767:11)
at Loader.resolve (internal/modules/esm/loader.js:97:40)
at Loader.getModuleJob (internal/modules/esm/loader.js:243:28)
at Loader.import (internal/modules/esm/loader.js:178:28)
at importModuleDynamically (internal/modules/cjs/loader.js:1116:29)
at importModuleDynamicallyWrapper (internal/vm/module.js:432:21)
at importModuleDynamically (vm.js:376:43)
at exports.importModuleDynamicallyCallback (internal/process/esm_loader.js:29:14) {
code: 'ERR_MODULE_NOT_FOUND'
} |
@aduh95 let's move the directory error right back into the resolver to make this easier by removing this code path here - https://github.com/nodejs/node/blob/master/lib/internal/modules/esm/resolve.js#L273 and adding the new directory error for It's a lot I know... but let me know if that all makes sense? |
Sorry the first code line should be this one - https://github.com/nodejs/node/blob/master/lib/internal/modules/esm/resolve.js#L273. |
@guybedford thanks for your last comment, I was about to ask for a TLDR 😅 I'll work on it tomorrow! |
4bb6e0b
to
80a6427
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Co-authored-by: Jordan Harband <ljharb@gmail.com>
@guybedford Any chance you have time to review this? I have implemented the changes you requested, if you want to have another look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
//cc @nodejs/modules-active-members
Adds hint when module specifier is a file URL. Refs: nodejs#31906
Great to see, yes I think that is fine to include that in this PR! Will run CI again now to land. |
PR-URL: nodejs#33220 Fixes: nodejs#33219 Reviewed-By: Guy Bedford <guybedford@gmail.com>
Adds hint when module specifier is a file URL. PR-URL: nodejs#33220 Fixes: nodejs#33219 Reviewed-By: Guy Bedford <guybedford@gmail.com>
Fixes: #33219
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes