Add hasDefaultExport to ModuleInfo #4356
Merged
+158
−39
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
This is the second Plugin API extension I am working on at the moment. This time the goal is to ease to creation of proxy modules that just "reexport everything" from another module.
The problem here is that
does NOT reexport everything from "foo"—it just reexports all NAMED exports. But if there was a default export, it will be lost (not sure why things were designed that way, but that is what the specs say and what Rollup does). So if you also want to reexport the default export as well, you have to know whether it exists before writing the proxy.
My suggestion (implemented in this PR) is to add a flag
hasDefaultExport: boolean | null
toModuleInfo
. The valuenull
is used for external modules and before the module has been parsed.When you
const moduleInfo = await this.load({id})
, then you can be sure that (if the module exists),moduleInfo.hasDefaultExport
is the correct value.@yyx990803, @patak-dev, @antfu, @marvinhagemeister not sure if this would be a problem to implement in Vite or WMR. My hope was that you already have some kind of information available, in the worst case you could probably do something with regular expressions executed when accessing a getter to figure this out.
Here is an example from the docs that shows how to use this:
I also considered if we should make the names of all exports available, but the problem here would be how to handle namespace reexports: If we do it right, we would need to merge the named exports of another module, and the logic would quickly get complicated and problematic, or invent a special syntax for that case, or ignore that case, none of which seemed right to me. So that is why I would go for this boolean for now.