module: CJS / ESM resolver sharing and refactoring#34744
Conversation
|
Review requested:
|
|
Wait, so now you can map your exports to things in node_modules?? Can you help me understand why that's a good idea? |
|
Sure, I can add it back, it's just that the spec was actually incorrect since it was only checking the package.json target path, when we in fact need to check both the target path and the user subpath. We give separate errors for these two cases because the one is package author issue while the other is a package consumer issue. This error separation doesn't apply as easily for patterns though so those errors may need to be rethought. I refactored it out because it seems overly strict and unnecessary but I can add it back. |
|
I think it's very critical that "exports" only be possible to use to remap an entry specifier to "a file within the package that has exports". |
|
@ljharb I've added back the node_modules restriction identically to previously with a refactoring to make it part of the new segment check approach. |
734865c to
fc1f44b
Compare
|
I would like to land this PR soon. Any further feedback welcome. |
|
@nodejs/modules-active-members for any further review |
PR-URL: #34744 Reviewed-By: Jan Krems <jan.krems@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
|
Landed in f8976a7. |
Broken locally for me since f8976a7. Refs: nodejs#34744
PR-URL: #34744 Reviewed-By: Jan Krems <jan.krems@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: #34744 Reviewed-By: Jan Krems <jan.krems@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: nodejs#34744 Reviewed-By: Jan Krems <jan.krems@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Previously, `requireStack` was attached only on the bottom fallback path of `Module._resolveFilename`. Errors thrown from `tryPackage`, `trySelf`, the `#imports` branch, `finalizeEsmResolution`, and from within `Module._findPath` (exports/imports resolution failures) all escaped without it, leaving the diagnostic uneven depending on which inner path failed. This change makes the diagnostic uniform across those paths via two helpers: * `buildRequireStack(parent)` walks the parent chain. It is called lazily on the error path only, so successful resolves keep their original cost and a pathological parent-chain cycle from `module.parent = module` cannot hang the hot path. * `attachRequireStack(err, parent)` applies the stack to an error when (a) the error code is in a `SafeSet` of module-resolution codes (`MODULE_NOT_FOUND`, `ERR_MODULE_NOT_FOUND`, `ERR_PACKAGE_PATH_NOT_EXPORTED`, `ERR_PACKAGE_IMPORT_NOT_DEFINED`, `ERR_INVALID_MODULE_SPECIFIER`, `ERR_INVALID_PACKAGE_TARGET`, `ERR_INVALID_PACKAGE_CONFIG`), (b) `err.requireStack` is not already an array, and (c) the error object is extensible. The last check protects against monkey-patched `Module._findPath` implementations that may throw frozen errors. The catch blocks in the `#imports`, `trySelf`, and `Module._findPath` paths delegate to `attachRequireStack`, and the bottom fallback uses `buildRequireStack` directly. Resolves two long-standing `TODO(BridgeAR): Add the requireStack as well` comments in `lib/internal/modules/cjs/loader.js`, originally deferred in nodejs#26823 (2019) and carried through nodejs#34744 (2020). Tests cover the `#imports`-to-missing-file case, the `ERR_PACKAGE_PATH_NOT_EXPORTED` case via self-require, a frozen- error monkey-patch (must not crash), and a preset non-array `requireStack` value (must be replaced). Existing assertions in `test-module-loading.js` and `test-module-loading-error.js` are extended to verify the new property on errors that previously lacked it. Signed-off-by: sangwook <rewq5991@gmail.com>
This extracts just the resolver refactoring component from #34718.
I hope that the negative diff speaks for itself at least!
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes