-
Notifications
You must be signed in to change notification settings - Fork 161
fix: move cache assets instead of copying them #883
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
Conversation
🦋 Changeset detectedLatest commit: be89859 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
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 |
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.
Thanks for the PR, but i don't think that's what we want to do.
We rely on a bunch of things from the .next folder itself and moving things from there will lead to something that break.
And this will also break some people's deployment, not something we'd want either.
What we should do here instead of copying the file, is to just use the files from .next to compute the cache files instead of copying them. This won't reduce the final size that much, but it will reduce the size used during the deployment itself.
Thanks that makes much more sense. I've attempted to refactor it so it's not copying the output and just works on the next output instead. |
commit: |
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.
LGTM Thanks.
Sorry for such a long delay.
fixes parts of #822
I'm not sure if this is the right approach though, as it mutates the
.next
directory by moving files from there directly to the .open-next dir.From a application with tons of static cache files i get the following difference:
But seeing that the .open-next dir is a bit smaller something might've broken. Running the app with open-next locally worked just fine though