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

deframe's avatar

Project build upon deployment

I have a serious hang-up at the moment regarding the project build process and the point at which it should happen during deployment.

At the moment my project has the following build process:

composer install --no-dev
npm install --production
bower install
gulp --production
rm -rf node_modules && rm -rf bower_components

The problem with this is the sheer amount of work that needs to be done just to get my project onto a server. Right now the Composer vendor folder is 14.3MB (~4,600 files), node_modules is 70MB (~11,000 files !!!) and bower_components is 3.3MB (271 files). Every single one of these files is downloaded or copied in from cache during the build process. Make a typo? Fix it and copy/download 15,000 files. Copy the fix from staging to production? 15,000 files again. Even when these files are cached, it takes a lot of time and server resources to run a deployment due to the large amount of version checking and copying.

Right now it's taking me about two minutes to deploy a nearly empty L5 project to a fairly beefy cloud server, and that's with the required Composer packages and Node modules being installed from cache.

What's annoying to me is that 'node_modules' and 'bower_components' are only needed temporarily. Once I've compiled my 'app.js' and 'app.css', both folders get deleted in order to clean things up, a process that takes time in itself due to the sheer number of files they contain.

So far I've hit upon the following potential solutions:

  1. Commit my compiled assets into VCS so there's no need to compile them during deployment. This is far from ideal as the rest of team members end up with conflicts on those assets, messy merge requests, etc. http://a-fro.com/keeping-compiled-css-out-of-git-on-acquia

  2. Install Gulp, Elixir, etc, globally on the server then symlink the global node_modules folder into my project source prior to running Gulp using 'npm link...'. This bypasses the need to install node_modules locally but it's very dangerous as the versions could get all screwed up (e.g. the recent parameter ordering change in Elixir's script functions would break the build process if the server's global version wasn't updated...)

  3. Copy Composer libraries from a previous build. Essentially this means comparing my composer.json and composer.lock file to that of a previous project build on the server. If they are identical, the 'vendor' folder from the old build is copied into the new one. If not, 'composer install' is run as normal. No package version checks/downloads unless they are absolutely required.

  4. Run the build inside a VCS working dir on the server. This means that a folder containing the project's repository would permanently exist on the server and during deployment a 'git pull' would be executed to bring it up to date. The build process outlined above would then be run in that folder, meaning that only new/updated dependencies would be downloaded. From there it's a matter of copying the required files to a clean build folder and serving it up. This kinda replicates what happens in a desktop/development environment.

I'm leaning towards the fourth option but there is still scope for things to go badly wrong. For example, if the build process adds something to the folder that isn't handled by the .gitignore file, subsequent 'git pull' commands won't work properly and the whole process will fail.

Does anyone have any other suggestions? I'm curious to know how teams of individuals go about deploying their projects in a safe, efficient way!

0 likes
0 replies

Please or to participate in this conversation.