-
Notifications
You must be signed in to change notification settings - Fork 205
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
Heroku slug size: can node_modules be deleted after build? #491
Comments
@nruth thanks for bringing this to our attention. Since Dynos and their filesystems are ephemeral, we cache If it's possible to remove directories from the slug, but keep them in the cache, that would be ideal. Are you interested in investigating that possibility? |
Yep that sounds good. I'm currently looking at a build-pack solution and will report back if I get it working. I've found one that removes files after other buildpacks and am trying it out on a staging remote. |
@nruth is the simplest solution introducing a |
Ah, I AM missing something:
|
Yep it seems like slugignore is more for excluding psd or pdf files from docs or artwork directories rather than cleaning up compilation artefacts. Probably needs a V2. The buildpacks give another way to do this, but it's broken and took some poking around to get a working build. When it worked, it reduced my slug size from ~296MB to 68MB by deleting the 3 ember project directories. The apps still seem to work after this, which I assume is because the compiled assets are stored somewhere in the rails app's asset pipeline instead of in those subdirectories? My specific configuration is 3 ember apps as subdirectories (specifically, git submodules with a machine-user key). I've changed the names but it basically looks like this: ember-cli-rails initializer:
where each is a subdirectory containing the full ember-cli project and all the leftover node_modules that were causing the problem. I don't know if dependency caching is working for my app so can't give a definite answer there, but the slug size is down and from what I understood of the buildpack docs the cache of the node or ruby buildpacks shouldn't be affected by another buildpack? Long-term we're going to move to a redis lightning-deploy type setup because heroku push is getting really really slow now, but short-term I just wanted to get the slug size away from the 300MB red line so we can continue deploying and updating our project without fear of heroku rejecting the changes. |
I'm not 100% confident this is correct yet, but going to continue with it through to production and see how it goes. It seems simpler than changing the gem. What do you think of wrapping this up by me making a readme PR for the Heroku deployment instructions that briefly describes the problem and links to this issue and the buildpack? |
Those gains are definitely worth mentioning in the README, maybe worth adding support to. 👍 Thanks for putting in the work! |
Just to follow up on my previous hedging, we've been using this in production without issues since my original posts. |
Just an FYI for anyone else who stumbles on this...this doesn't work if you're using the Here's what my
|
Closes tricknotes#491. [Heroku slug size is limited](https://devcenter.heroku.com/articles/slug-compiler#slug-size). The build process creates artifacts that are not necessary for the server to run, but are included in the deployed Heroku slug. Omitting these build assets can dramatically reduce slug size. A build-pack solution for this is discussed in [Issue tricknotes#491][tricknotes#491]. [tricknotes#491]: tricknotes#491
3 apps takes the slug size up towards 300MB, and it looks like most of this is in node_modules that shouldn't be necessary after the precompile step creates the javascript and css assets?
Poking around with
heroku run bash
anddu
is showing the node_modules directories as being around 200-500MB which will zip to some extent but shouldn't be necessary.Is there a reason I've not thought of for keeping these around in the final dyno slug, or could we add something to delete the files from the slug once asset compilation succeeds?
There's something similar in the Heroku docs for Java.
The text was updated successfully, but these errors were encountered: