fix: optimize deps on dev SSR, builtin imports in node #8854
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.
Description
Follow up to:
These changes were triggered by a report from @DylanPiercey while testing Vite v3 with Marko.
Refactor
Even if the PR looks big, the main change is a straight forward refactoring from:
to
We need this because we have now added more responsibilities to the optimizer, like tracking of the iddle state before optimizing. Having separate optimizers allows us to cleanly make the calls from the ssr pipeline noop. See later in the code:
Before this PR, there could be race conditions between the SSR requests and regular requests when registering ids in
delayDepsOptimizerUntil
.New experimental optimizeDeps.devSsr option
Edit: This is no longer needed, the optimizer is started on the first ssrLoadModule call
Before this PR, there was a simple condition to check if we should optimize deps for dev SSR:
This was generating runs of the dev SSR optimizer when using the Vue plugin, since it auto injects vue as
ssr.noExternal
.The PR right now adds an option to opt-in.
Note: I think we could change this to init the optimizer automatically on the first call to
ssrLoadModule
.Passing SSR state to esbuildDepPlugin
In SSR, before this PR we ended up with
browserExternalId
for node modules in CJS. Forwarding the ssr flag fixed this issue.Patching Esbuild dynamic require error
The last issue with the added test case seems to be an unresolved esbuild bug:
This PR implements the
banner
workaround mentioned here evanw/esbuild#1921 (comment). Interested in your feedback @benmccann since I saw you participating in that threadWhat is the purpose of this pull request?