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
fix: push manifest #1680
fix: push manifest #1680
Conversation
🦋 Changeset detectedLatest commit: 86338c6 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
e3981ec
to
d98b87f
Compare
const isESM = filename => /\.esm\.js$/.test(filename); | ||
const isMatch = (filename, condition) => isESM(filename) === condition; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In case this raises an eyebrow, the asset manifest will always map to ESM output if enabled, CJS if it's not. We don't need to deal with that ourselves anymore.
There's a new test to ensure the push-manifest.json
is correct and referring to ESM scripts when ESM is enabled.
What kind of change does this PR introduce?
Bug fix / refactoring for future use
Did you add tests for your changes?
Yes
Summary
Closes #1675
In short, the
push-manifest.json
output had hard-coded expectations that caused two problems in the linked issue:"undefined"
entry in thepush-manifest
This fixes both issues by using
webpack-manifest-plugin
(Webpack really should make this part of core, extremely useful to expose this info to other plugins).This plugin provides a map output assets that allows us to keep our expectation about a
bundle.css
orroute-home.js
existing, but allows users to still customize the actual output. For example, the following config:...would create the following manifest:
Should allow users to customize output names as they wish without it interfering with any assumptions we've made about output.
In the future we might be able to make greater use of this and move away from asset path concatenation like the following:
preact-cli/packages/cli/lib/resources/head-end.ejs
Line 1 in a56d904
However, for now, I'd hesitate to do that as this might break some configs. Better to wait for a major.
Still, it should allow for much more robust targeting of output assets as it won't fall to pieces if a user makes configuration changes.
Does this PR introduce a breaking change?
No