Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

driesvints's avatar

Laravel Elixir dependencies timeout when deploying to Forge

I've just update to Laravel 5 and at the same time refactored my frontend asset compiling to Laravel Elixir. I've update my Forge deploy script so that it will npm install and compile the assets on the server (because I don't want to commit them to my source code).

However, when the deployment script runs it always gets killed off on Forge for no reason whatsoever. It just says killed. When I look at the node_modules folder locally, it says it's about 137 MB large. I don't know if that's normal but that's really insanely large, imo? Could it be that the Forge server can't handle installing that many dependencies? I'm really just using the basic Elixir dependencies and one more for image compressing.

Here's my package.json: https://github.com/driesvints/driesvints.com/blob/master/package.json
That's also the source code for my website so you can find anything you need there.

Here's my Forge deploy script:

cd /home/forge/default
php artisan down
git pull origin master
composer install --no-dev
npm install
npm install -g bower
bower install
./node_modules/.bin/gulp --production
php artisan up

So it basically gets killed off somewhere during npm install.

Can anyone please help me or put me in the right direction at what I might be doing wrong? I'm really stuck with this.

0 likes
7 replies
alenabdula's avatar
Level 13

Did you try SSHing directly into the server and install via terminal? Just to eliminate Forge as an issue.

Having your server do all that processing on every deploy doesn't seem practical to me. Is there a reason you decided to compile server side? What happens when you get thousands of image assets? How long will that take to compile and deploy... I'm just wondering as I always compile assets locally using my own Gulp setup.

driesvints's avatar

@alenabdula yes, I tried that. The script gets killed somewhere when I run npm install.

You'd just compile locally and deploy that way? I'm not really sure if I want the compiled assets in my source code? Is that a best practice for asset compiling? I always thought it would be best to avoid committing compiled assets.

alenabdula's avatar

I'm not really sure if I want the compiled assets in my source code?

I just don't understand the concern. I compile CSS/JavaScript and Web Site Graphics into public folder, keep that in "source code" (you mean version control?). Then I can exclude any folders from version control that contain other media types like video, photos, PDF and etc. And back this data up.

driesvints's avatar

you mean version control?

Yes! Sorry for the bad wording.

I took your advice and committed the compiled assets. My deployment is now fixed and super fast!

Thank you so much for suggesting this. I don't really know why I never did this before. Should have done this much sooner. Thanks again!

rovansteen's avatar

Compiled assets shouldn't be in your version control in my opinion. It doesn't make any sense to have a minified css file for example in your version control because first of all the differences are useless and second when you revert such file it's no longer correctly corresponding with your source files. Also, big chance you have different compiled assets depending on your environment. I don't minify my css or uglify my javascript on develop for example. So that makes this process very annoying for me.

To tackle this problem, if you ssh in your forge server and go to your application directory and run 'npm install' do you get any errors?

alenabdula's avatar

first of all the differences are useless and second when you revert such file it's no longer correctly corresponding with your source files

What differences? Again I don't understand the concern. I don't care about the minified file, it's just in version control. It gets recompiled on every build if something needs to change. Maybe I just don't see it as servers responsibility to compile assets and therefore don't see the potential benefits. I would love some pros/cons of this approach maybe I'm missing something.

big chance you have different compiled assets depending on your environment

This is where Gulp tasks come in.

To tackle this problem, if you ssh in your forge server and go to your application directory and run 'npm install' do you get any errors?

See

yes, I tried that. The script gets killed somewhere when I run npm install.

rovansteen's avatar

It sounds like you are just using version control to get your code from your local development environment to a production environment. Nothing wrong with that, but version control also gives you the power to control which version is currently on that production environment for example. So if you fuck up something in your CSS, you have the ability to revert to an older commit. But if you have minified CSS in your version control it's hard to keep track to which CSS corresponds to which SASS , especially if you are working on a team. You have to commit a new compiled css file with every sass change, and believe me, this is easily forgotten. To me and my team this is definitely a no-go.

About the second point: yes you can use Gulp for that, but my point is that I don't want to minify my css during development because that slows the compiling down. So that means I run just 'Gulp' locally, and run 'Gulp --production' on the server side. But if you want to commit all the production assets, every time you want to commit something you have to exit Gulp watch, run Gulp --production and commit. That's very annoying in my opinion.

I've read his comment ;) I'm asking for any errors, or at least the terminal output.

Please or to participate in this conversation.