feat(commonjs): Add ignore-dynamic-requires option #819
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.
Rollup Plugin Name:
commonjs
This PR contains:
Are tests included?
Breaking Changes?
If yes, then include "BREAKING CHANGES:" in the first commit message body, followed by a description of what is breaking.
List any relevant issue numbers:
Description
As I am doing more Node bundling, I sometimes want to completely externalise a dependency (because it is doing evil things) but do so in a way that the exact execution order is preserved. So what I want is to keep an untranspiled require statement. This works well for static requires but is just not possible for dynamic require statements EXCEPT if you use a loophole: If you specify some dynamicRequireTargets but do not use them, the dynamic require function injected will do an actual require as fallback.
Now this is not nice for two reasons:
The goal of this PR is to make this a conscious decision:
ignoreDynamicRequires
is set totrue
, dynamic requires will either be left untouched, or ifdynamicRequireTargets
is used, will get the currentrequire
fallbackignoreDynamicRequires
is set tofalse
or left unspecified, then dynamic requires will always throw an error if they cannot be resolved viadynamicRequireTargets
.You already got this error before without the
dynamicRequireTargets
option, the breaking change is that you now also get it whendynamicRequireTargets
is specified. I feel this is much more consistent and hopefully worth the break. We could make it non-breaking by changing the default, though. On the other hand, maybe we can couple this with #658?The naming choice was made to extend the
ignore
option that does the same for static require calls.Possible future extensions that I would see as out-of-scope for now but we could easily add if there is demand:
ignoreDynamicRequires: "stub"
that replaces unresolved dynamic require calls with an empty object? This might be the more useful version, that way, tree-shaking could later easily clean up these calls without side-effects. But again, only if there is actual demand.