Skip to content
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.

Sign up for GitHub

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

Jump to bottom

generateBuildId could use hash of content #12087

Closed
zacanger opened this issue Apr 22, 2020 · 3 comments · Fixed by #14279
Closed

generateBuildId could use hash of content #12087

zacanger opened this issue Apr 22, 2020 · 3 comments · Fixed by #14279

Comments

@zacanger
Copy link

zacanger commented Apr 22, 2020 •
edited
Loading

Feature request

Because the fallback generateBuildId is a nanoid, cache is busted on bundles even if they haven't changed between builds. It's possible to implement your own, of course, but that behavior seems unexpected for users migrating from using their own custom Webpack config. This results in clients re-fetching client-side JS when it's not necessary.

Describe the solution you'd like

generateBuildId's fallback if not defined in config could be based on a hash (md5, or whatever) of file contents, and preferably be lowercased as well to avoid issues with hosting on S3, middleware in custom servers, etc.

Describe alternatives you've considered

I started trying to implement it as a custom generateBuildId but figured I should raise the issue here first in case it's something anyone else is considering.

Additional context

Example: Two builds run right after each other, no changes:
image
@zacanger zacanger reopened this Apr 22, 2020
@zacanger zacanger changed the title generateBuildId could use md5 of content generateBuildId could use hash of content Apr 22, 2020
@timneutkens
Copy link
Member

Duplicate of #6303

@timneutkens timneutkens marked this as a duplicate of #6303 Apr 22, 2020
@zacanger
Copy link
Author

Ah, for some reason I missed that when searching, my bad.

@timneutkens timneutkens mentioned this issue Jun 20, 2020
Merged
kodiakhq bot pushed a commit that referenced this issue Jun 20, 2020
@timneutkens
Update filename generation for client-side compilation (#14279)
bef9b56 
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
rokinsky pushed a commit to rokinsky/next.js that referenced this issue Jul 11, 2020
@timneutkens @rokinsky
Update filename generation for client-side compilation (vercel#14279)
0fe6fd8 
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
@balazsorban44
Copy link
Member

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@vercel vercel locked as resolved and limited conversation to collaborators Jan 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Update filename generation for client-side compilation timneutkens/next.js
3 participants
@timneutkens @zacanger @balazsorban44