-
Notifications
You must be signed in to change notification settings - Fork 26.5k
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
hash the font file name if it exceeds our max file size #69144
base: arlyon/font-code-refactor
Are you sure you want to change the base?
hash the font file name if it exceeds our max file size #69144
Conversation
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
5f85b3b
to
7951fad
Compare
Failing test suitesCommit: 5f85b3b
Expand output● app dir › HMR › should not cause error when removing loading.js
Read more about building and testing Next.js in contributing.md. |
What?
When using google fonts, we import files and write them with their hash to the filesystem. Some of these fonts get very close to the file size limit which, after appending a hash onto them, causes turbo to fail with a write error.
Why?
Different operating systems have different path length requirements. In short:
We need to respect these.
How?
A small change in the font code that rewrites filesystem paths if they approach this limit, with some buffer room. Rather than truncating I opted for a 64 bit hash because many fonts have long common prefixes. We could bump this up to 128 or higher but in practice there will be very very few files that need this code path.
Another option is a general handler for this where reads and writes are intercepted in turbo tasks fs but I wanted to achieve a few things:
To me it is safer to have the source ensure they are meeting the needs of the system since we can control source specific implementations.
Closes PACK-3012