module: better error for named exports from cjs #33256
Conversation
nodejs-github-bot
added
the
esm
|
Definitely a +1 to this, it is much needed. Ideally the error message could contain the exact context and solution, eg something like:
|
|
@guybedford getting the specific named export that was attempted to be imported would be a bit more work digging into the internals (is a hidden part of the error message). Happy to include the solution regarding the default but was unsure how verbose to be |
|
|
@GeoffreyBooth … jinx ;) |
|
Ok... I've accepted the proposed changes and made another stab at the text. Currently it uses a generic module name and named imports... We should be able to make the error message include the explicit named imports that were used but I'll need to dig in a bit how the message is being decorated with the arrow to do this. |
|
ok... it is gross but it works 🎉. Added options argument to the decorate error function and utilized the existing code that grabs the failing import statement. Errors will now point out the error and offer alternative working code. |
|
I'm not up to date enough in that space right now to approve IMO but changes LGTM. I just want to make sure that semverness is taken into account and that if modules are stable we make sure to choose the appropriate semverness for an error message change. |
|
@benjamingr ESM is still marked experimental in the docs and changes are not subject to Semver |
|
@MylesBorins thanks for this! much appreciated |
|
This is catching a V8 error, not an node.js error. I can double check but I
don't believe these errors have error.code
…On Wed, May 6, 2020 at 5:18 PM Jordan Harband ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In lib/internal/modules/esm/module_job.js
<#33256 (comment)>:
> @@ -92,7 +94,22 @@ class ModuleJob {
this.module.instantiate();
}
} catch (e) {
- decorateErrorStack(e);
+ if (e.message.includes('does not provide an export named')) {
+ const rootURL = this.module.url;
+ const childSpecifier = StringPrototypeMatch(
+ e.message,
+ // Match the first string in either single or double quotes
fair enough; it still seems safer to me to use error codes to pivot, and
to store this information as a property on the error rather than parsing it
out of the error message
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#33256 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADZYVZE2I67XE62JGFUFMLRQHHYTANCNFSM4MZ4EM7Q>
.
|
MylesBorins
force-pushed
the
better-cjs-named-export-error
branch
from
69199b7 to
7a40821
Compare
|
PTAL I've added tests and refactored pretty significantly including documentation in the code that gets a bit funky. I do not have tests for specifiers that have escaped quotes as my various manual tests seem to imply it is impossible to import esmodules in Node.js with escaped quotes in the specifier. If my assumption here is wrong someone please let me know. |
Not sure what you mean. This works: |
|
OK... so it looks like escaped strings can work as specifiers... and it also looks like V8 normalizes this before printing a message... so independent of if single or double quotes have been used, if quote inside the string are single / double or escaped, the message will always include only single quote 😅 I've gone ahead and removed the use of a regular expression and am instead manually separating the string based on knowing the shape it will be (this is hardcoded into V8). If this changes internally in V8 all the tests will blow up. |
MylesBorins
force-pushed
the
better-cjs-named-export-error
branch
from
603a879 to
06cdf08
Compare
|
OK... so this was a wild ride but I've fixed all the things. I didn't write a test for the indirection sub package.json edge case I was thinking could be an issue... but all child modules, including bare imports, are 100% being resolved relative to the file that the import statement was contained in 🎉. This should cover all cases of escape characters, although might give inaccurate results depending on the string we get from V8. |
| @@ -0,0 +1,3 @@ | |||
| module.exports = { | |||
| comeOn: 'fhqwhgads' | |||
There was a problem hiding this comment.
Maybe foo would be more appropriate here?
There was a problem hiding this comment.
i don't see how anything could possibly be more appropriate than this particular reference
We do not support importing named exports from a CJS module. This change decorates the error message for missing named exports in the case where the module being imported is expected to be CJS by the ESM loader. Signed-off-by: Myles Borins <[email protected]>
MylesBorins
force-pushed
the
better-cjs-named-export-error
branch
from
d0df6ab to
75f08f9
Compare
|
CI is green. Going to land this EOD unless there are any blockers |
We do not support importing named exports from a CJS module. This change decorates the error message for missing named exports in the case where the module being imported is expected to be CJS by the ESM loader. Signed-off-by: Myles Borins <[email protected]> PR-URL: #33256 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>
|
Landed in 2c3c9f5 |
We do not support importing named exports from a CJS module. This change decorates the error message for missing named exports in the case where the module being imported is expected to be CJS by the ESM loader. Signed-off-by: Myles Borins <[email protected]> PR-URL: #33256 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>
We do not support importing named exports from a CJS module. This change decorates the error message for missing named exports in the case where the module being imported is expected to be CJS by the ESM loader. Signed-off-by: Myles Borins <[email protected]> PR-URL: #33256 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>
We do not support importing named exports from a CJS module.
This change decorates the error message for missing named exports in
the case that the module being imported is expected to be CJS by the
ESM loader.
Some high level questions
Needs a test, but wanted to confirm folks would be open to doing this before hacking on a test.