-
Notifications
You must be signed in to change notification settings - Fork 27.2k
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
Can't use [chunkhash] for files #4255
Comments
Doing:
Is currently not supported, since you're changing the output of all files, instead of specific ones you're generating. Adding hashes to page files is going to be up to us the future. The pages-manifest.json wasn't added as a way to support , instead it was added as a way to speed up page resolving. We don't ship this manifest to the client side, that's why pages can't be hashed like this. |
Hi Tim Do you think this would be a nice feature? What is your estimated level of effort to get this going? If not incredibly high, I am thinking of implementing it myself? |
Updates the way filenames are generated for browser compilation. Notably: - All entry bundles now have hashes in production, this includes pages (previously pages used a buildId in the path) - The AmpFiles no longer depends on hardcoded bundle names, it uses the buildManifest instead (internals) - All cases where we match the page name from the chunk/entrypoint name now use the same function `getRouteFromEntrypoint` (internals) - In development we no longer include the "faked" `buildId` set to `development` for page files, instead we just use the `/_next/static/pages` path (was `/_next/static/development/pages`). This was changed as it caused unneeded complexity and makes generating the bundles easier (internals) - Updated tons of tests to be more resilient to these changes by relying on the buildManifest instead of hardcoded paths (internals) Follow up of these PRs: #13759 #13870 #13937 #14130 #14176 #14268 Fixes #6303 Fixes #12087 Fixes #1948 Fixes #4368 Fixes #4255 Fixes #2548
Updates the way filenames are generated for browser compilation. Notably: - All entry bundles now have hashes in production, this includes pages (previously pages used a buildId in the path) - The AmpFiles no longer depends on hardcoded bundle names, it uses the buildManifest instead (internals) - All cases where we match the page name from the chunk/entrypoint name now use the same function `getRouteFromEntrypoint` (internals) - In development we no longer include the "faked" `buildId` set to `development` for page files, instead we just use the `/_next/static/pages` path (was `/_next/static/development/pages`). This was changed as it caused unneeded complexity and makes generating the bundles easier (internals) - Updated tons of tests to be more resilient to these changes by relying on the buildManifest instead of hardcoded paths (internals) Follow up of these PRs: vercel#13759 vercel#13870 vercel#13937 vercel#14130 vercel#14176 vercel#14268 Fixes vercel#6303 Fixes vercel#12087 Fixes vercel#1948 Fixes vercel#4368 Fixes vercel#4255 Fixes vercel#2548
With next v6.0.0, there is a manifest plugin written by @timneutkens. It should allow one to alter the webpack filenames like this in
next.config.js
:NOTE: I have overridden
_document.js
Expected Behavior
I would expect all file names to be hashed, and for next to have a proper mapping from the original file name to the hashed filename.
Current Behavior
_document.js
is excluded from this mapping, so things fail.Steps to Reproduce (for bugs)
next.config.js
by using the code pasted at the start of this bug_document
I have a suspicion (although unconfirmed) that
_error
and_app
will also suffer from this (if overridden).The text was updated successfully, but these errors were encountered: