Add importedIdResolutions and dynamicallyImportedIdResolutions to moduleInfo #4354
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.
This PR contains:
Are tests included?
Breaking Changes?
List any relevant issue numbers:
Description
I am currently working on stream-lining the process of scanning dependency trees via
this.load
and the use ofthis.load
in general. One problem I stumbled upon is this small detail that is easy to get wrong:meta
(orsyntheticNamedExports
ormoduleSideEffects
) tothis.load
, then it will be ignored UNLESS this is the first time we try to load this module.The reason these flags exist on
this.load
in the first place, and why they are ignored for subsequent calls, is that they simulate theresolveId
hook. This hooks can attach meta information to a module, but this will only happen on first resolution. This is important e.g. for the node-resolve plugin.Ignoring subsequent calls makes sure that information from a
load
ortransform
hook is not accidentally overwritten by information from aresolveId
hook, or information passed viathis.load
. I.e. meta information is always attached in this order:resolveId
hook orthis.load
callload
hooktransform
hooks in order of pluginsHowever, that means you have to get these flags right when loading a module via
this.load
that may not have been loaded another way.When scanning a dependency tree by looking at the
importedIds
on moduleInfo, you currently only find out the imported ids, but there is no way of figuring out the additional meta information (you can try runningthis.resolve
, but as you do not know exactly how the imports were created, you will have a hard time getting it right when e.g. the commonjs plugin is involved).This PR fixes this by not only exposing the imported ids, but also the resolution objects created by the
resolveId
hooks so that those can be passed tothis.load
.There are two new properties on
ModuleInfo
(that Rollup implements as getters):importedIdResolutions: ResolvedId[]
dynamicallyImportedIdResolutions: ResolvedId[]
The latter corresponds to dynamic imports, but only those that can be statically resolved (others are missing entirely).
@yyx990803, @patak-dev, @antfu, @marvinhagemeister also looking forward to your comments, I hope this would be easy to implement in Vite and WMR. There will be another two PRs shortly to improve other aspects of the use of
this.load
, though.