feat(externals): support aliasing traced packages #1553
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
π Linked issue
β Type of change
π Description
Normally when using the
resolutions
field to use an aliased package (say original name isa
and aliased fromnpm:b
), the package manager downloadsb
with and copies all contents intonode_modules/a
(whilenode_modules/a/package.json
is package withname: b
.). We use "directory" name as authentic package name to copy into.output/server/node_modules
pnpm also does this but there is a catch! the
node_modules/a
is a symbolic link tonode_modules/.pnpm/b
. When we are running external tracer, we follow the links and assume the real name isb
which is wrong. To add to the complexity, rollup, mlly and nft also resolve real paths in various places so it is almost impossible to trace aliaces without manually specifying. (We might auto detect from root levelpackage.json
usingresolutions
andaliases
)This PR enables new
externals.traceAliases
option in order to speficy trace aliased packages:This tells nitro when tracing
.output/server/h3-nightly
, try to link it to.output/server/node_modules/h3
.(
h3-nightly
alias is added by default as a known dependency)Isolated Preset Testing
This PR enables a new isolated way of testing presets.
Previously, we were running fixture build output within
/<repo>/test/presets/.tmp/node
. Even if an external like h3 is missing, tests were wrongly passed since Node.js also searches in/<repo>/node_modules
. The tests are now more secure by using/tmp/nitro-test/<preset>/output
.π Checklist