optional ES-module compatibility setting #1548
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.
This introduces a new option that opts-in to stricter behavior when we're trying to help v1 addons access legacy AMD modules. Previously, we always depended on looseness in webpack that allows us to mix CJS (which could fully-match the runtime egacy AMD behaviors) and ES modules. We would emit a CJS shim for each unknown module that would locate the module in the AMD loadeder at runtime.
With this new setting
amdCompatibility: { es }
, no automatic shims get emitted for missing modules. Instead you must manually list specific shims that you need (because the ES modules shims need their exports known statically in advance).This setting is only recommended when also setting
staticEmberSource: true
, because otherwise ember itself needs a whole lof shimming.In addition, this PR includes some defensive improvements to our rollup and babel plugins so that they filter query params off of filenames. This makes them more robust in build systems like vite that like to tack cache-busting query params onto everything.