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

Tips on Save/restore yarn cache #1183

Closed
krnjn opened this issue Aug 5, 2021 · 3 comments
Closed

Tips on Save/restore yarn cache #1183

krnjn opened this issue Aug 5, 2021 · 3 comments

Comments

@krnjn
Copy link

krnjn commented Aug 5, 2021

Just replying to #654 (comment) (since that convo is locked, but @schneems feel free to copy / paste this directly as a collaborator on the buildpack -- I just would want people to have the full knowledge / suggested approach but agree with your decision to close that thread, just wish this was the last thing under the wire there!)

@philippegirard good to hear that it worked for you -- just as a flag for others who are using the split chunks approach (we're still on an older version of webpacker) this part of the docs is pretty important (posting screenshot since I can't link to the exact section):

Screen Shot 2021-08-05 at 8 56 28 AM

We do a sort of crazy thing in our app where each rendered view (including all of it's partials) simply provide the packs that it want's to use on it's page, and then we call the javascript_packs_with_chunks_tag in the head tag on the application layout page once. This is roughly how this works in our app:

# app/views/users/index.html.erb (specific view)

<div id='users-index-react'></div>

<%= provide(:javascript_page_packs, 'users/index') %>

# app/views/layouts/application.html.erb (this is the template which `yield`s the view above)
<!DOCTYPE html>
<html>

<head>
<%= javascript_packs_with_chunks_tag(*yield(:javascript_page_packs).split(', ').compact.unshift('application') %>
</head>

<body>
  <%= yield %>
</body>

</html>

We haven't upgraded, but seems like this has also become the suggested approach in the latest version of webpacker as well (albeit with the javascript_pack_tag, not a javascript_packs_with_chunks_tag).

RE: the comment from @schneems I wholeheartedly empathize / agree with this position:

Harder still, in this case, is that webpack hasn't converged on a "just works" solution and webpacker/rails haven't adopted that solution. When a rails new sets up webpacker to work with caching out of the box, then the story changes dramatically.

I've had a lot of pain over the years at multiple companies configuring @rails/webpacker to work properly "out of the box" with seemingly basic things like cached dependencies / optimizations and wouldn't necessarily blame the ruby buildpack here! ❤️
@krnjn
Copy link
Author

krnjn commented Aug 5, 2021

Closing since this isn't an actual issue, but I think is helpful for people who are looking for solutions -- thanks for all that you do @schneems !

@krnjn krnjn closed this as completed Aug 5, 2021
@schneems schneems mentioned this issue Aug 5, 2021
Open
@philippegirard
Copy link

philippegirard commented Aug 5, 2021 •
edited
Loading

Hey @krnjn thanks for flagging this! I wanted also to respond to @schneems.

TLDR:
To sums it all:

Make the important easy, make the rest possible

Heroku should allow users to specify directories to cache or cache /public/packs by default. It would make it possible solve this issue for Heroku power users. This solution also decouples itself from the larger buildpack rewrite projects. This is an issue affecting all the people using the React / RoR stack on Heroku.

Detailed answer:
The SplitChunk solution is just a work around the bigger issue: caching webpack builds in Heroku Ruby buildpack.

We need Heroku Ruby buildpack to cache public/packs the same way .node_modules is cached. Cache invalidation is not even needed, as re-running rails assets:precompile re-bundle only the files that changed (super efficient process).

However, as pointed webpack/webpacker caching which isn't standardized and isn't even supported via heroku/nodejs yet. I think to solve this Heroku should allow to specify additional cache directories in package.json (or other config file) exactly like it's done in the node-js buildpack with the cacheDirectories parameter : https://devcenter.heroku.com/changelog-items/641

Opinion (not facts):
I understand that caching and cache invalidation is an infamously hard topic in CS and that supporting sprockets caching is likely the single most costly feature the buildpack has ever taken on (in terms of support tickets and debugging hours). However, giving the possibility to power user like us to specify directories to cache with a clear interface should not result in costly support tickets, since this is opt-out by default feature and there is minimal "magic" underneath.

@schneems
Copy link
Contributor

schneems commented Aug 5, 2021

Heroku should allow users to specify directories to cache or cache /public/packs by default.

We do make it possible, but we don't make it easy, the interface to do this is via other buildpacks. Maybe this comment will help: #892 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@schneems @krnjn @philippegirard