Treat re-exports of '*' from empty files as ESM #9079
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.
↪️ Pull Request
Background
Many packages written in e.g., TypeScript are built for publishing to NPM by stripping types from the source files. This can lead to situations where ‘types-only’ files are stripped of all of their type definitions, leaving completely empty files behind. If there are imports from these ‘types-only’ files that are not also stripped (e.g., they re-export
*
from the module without thetype
keyword), then the resulting package ships with a dependency on a completely empty file.Current Behavior
This is a conundrum for Parcel, as it’s not clear what to do about the empty file when resolving. The current behavior is to treat these files as ‘dynamic CJS’ (to account for scenarios where
module.exports
might be modified outside of the module itself).The Problem
However, this is suboptimal for what is probably the most common case (as described in the first paragraph); ideally Parcel would treat these empty files as ESM with empty exports, and thus avoid the deopt to dynamic resolution altogether.
Suggested Change
The compromise solution here is to treat these empty files as ESM only if the asset is known to have no side effects (e.g., the package defines
sideEffects: false
), and keep the 'dynamic CJS' behavior as the fallback.✔️ PR Todo