New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add hook to rewrite dynamic import expressions #3449
Conversation
Thank you for your contribution! ❤️You can try out this pull request locally by installing Rollup via
or load it into the REPL: |
Codecov Report
@@ Coverage Diff @@
## master #3449 +/- ##
==========================================
+ Coverage 95.02% 95.08% +0.05%
==========================================
Files 171 171
Lines 5852 5861 +9
Branches 1727 1732 +5
==========================================
+ Hits 5561 5573 +12
+ Misses 157 156 -1
+ Partials 134 132 -2
Continue to review full report at Codecov.
|
2e6edae
to
e617dbd
Compare
…string in resolveDynamicImport
acc8e87
to
94c2955
Compare
94c2955
to
aad9f32
Compare
This PR contains:
Are tests included?
Breaking Changes?
List any relevant issue numbers:
Resolves #3232
Resolves #3444
Description
This will add a new
renderDynamicImportHook
that allows to completely rewrite how dynamic imports are loaded, see below for details.Also, this soft-deprecates the
output.dynamicImportFunction
in favour of the new plugin hook. There will be no warning yet but using the option will throw when using thestrictDeprecations
option. With the next major, a warning will be shown for all users.Moreover, this will add
dynamicallyImportedIds
to the object returned bythis.getModuleInfo
.Furthermore, this fixes an issue where
.js
extensions were also stripped from dynamic imports in AMD modules if the user supplied a custom string that happened to have a.js
extension.Internally, this removes the
defaultPlugin
entirely and replaces it with custom code in the places where the hooks are triggered. This solves some type issues (i.e. the defaults provided by the default plugin were not respected in the return type of running the hook) and also makes sure that errors in the default handlers are not confusingly reported as belonging to someRollup Core
plugin.From the added documentation:
renderDynamicImport
Type:
({format: string, moduleId: string, targetModuleId: string | null, customResolution: string | null}) => {left: string, right: string} | null
Kind:
sync, first
This hook provides fine-grained control over how dynamic imports are rendered by providing replacements for the code to the left (
import(
) and right ()
) of the argument of the import expression. Returningnull
defers to other hooks of this type and ultimately renders a format-specific default.format
is the rendered output format,moduleId
the id of the module performing the dynamic import. If the import could be resolved to an internal or external id, thentargetModuleId
will be set to this id, otherwise it will benull
. If the dynamic import contained a non-string expression that was resolved by a resolveDynamicImport hook to a replacement string, thencustomResolution
will contain that string.The following code will replace all dynamic imports with a custom handler, adding
import.meta.url
as a second argument to allow the handler to resolve relative imports correctly:The next plugin will make sure all dynamic imports of
esm-lib
are marked as external and retained as import expressions to e.g. allow a CommonJS build to import an ES module in Node 13+, cf. how to import ES modules from CommonJS in the Node documentation.