Deprecate hasModuleSideEffects in favor of moduleSideEffects and ensure it is mutable on ModuleInfo #4379
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 fixes an inconsistency in the naming i.e. we are using the
moduleSideEffects
option in theresolveId
,load
andtransform
hooks, but onModuleInfo
it is calledhasModuleSideEffects
. This becomes more problematic if you want to change this property explicitly onModuleInfo
.This PR does several things:
moduleSideEffects
onModuleInfo
(e.g. viathis.getModuleInfo()
) that takes the role ofhasModuleSideEffects
hasModuleSideEffects
andstrictDeprecations
istrue
hasModuleSideEffects
non-enumerable to avoid accidentally triggering the warning and basically hide the old option (though it still works to prevent breaking changes)moduleSideEffects
can be written during build time, which is important if you write e.g. an entry point proxy plugin that needs to set this flag totrue
for the original entry point (I also updated theinject-polyfill
example in the docs to reflects this)