Skip Webpack when Testing

 Let’s talk about getting rid of NodeJS in your CI pipelines.

I run Chipper CI (continuous integration for Laravel). I’ve always been annoyed that Webpack builds take more time and cause more issues than the actual valuable part of a CI pipeline.

The majority of us just need to run our tests and perhaps kick off a deployment. Node build tasks add a bunch of time and require way more CPU/RAM usage.

What if we just didn’t need Node in our pipeline? Can we just … not?

The answer is: Definitely, maybe!

Feature Tests

Very often, the only reason to build static assets in a CI pipeline is to generate the mix-manifest.json file.

This allows the mix() helper to work when running Laravel Feature tests. The feature tests make HTTP calls into your app, and thus often render blade templates that use the mix() helper.

If you don’t have a manifest file, an error is thrown!

Generating this manifest file involves building your static assets - in other words, using npm (or yarn) to install dependencies and run Webpack tasks:

1# Build static assets
2 
3npm ci --no-audit
4npm run dev

Sidenote: You should almost definitely be committing your package-lock.json file and running npm ci --no-audit instead of npm install!

If you take a look at your public/mix-manifest.json file, it likely looks something like this (with or without hashes, depending on if you enabled versioning):

1{
2    "/js/app.js": "/js/app.js",
3    "/js/foo.js": "/js/foo.js",
4    "/css/app.css": "/css/app.css"
5}

Here's the kicker: You don't necessarily need this file to exist for your tests!

Within your test's setUp() method, you can add the following magic:

1protected function setUp(): void
2{
3    parent::setUp();
4 
5    $this->withoutMix();
6}

With that in place, the mix() helper won't return any errors with a missing manifest file. Your tests can pass without needing to run NodeJS tasks!

Another thing you can do is create a manifest file for your CI pipeline that you copy for testing.

Let's say our Mix config generates the above mix-manifest.json file. We can commit a dummy manifest file to tests/mix-manifest.json, and it will always be available!

Then, in our CI pipeline scripts, we can use that file instead of installing/building our Node dependencies:

1# What if we created a mix-manifest.json file just for testing?
2# During CI, we can just move it where it needs to go
3cp tests/mix-manifest.json public/mix-manifest.json
4 
5# And then run your tests, no NodeJS required!
6php artisan test

With this file in place, the mix() helper will work, and your feature tests can pass without issue!

This (or any method!) that creates a correct manifest file can help you save a LOT of time and server resources in your CI build pipelines.

You'll need to update your tests/mix-manifest.json file anytime you change your configuration in a way that adds files to the real manifest file.

When do you need to build assets?

Sometimes, you do need to build assets in your CI pipeline! Here’s the most common times you need to:

1. When you build production assets to bundle them up into an “artifact” (zip file, container image, etc) that you can deploy
2. When you run other node commands as part of your test suite, such as eslint
3. When you are browser testing with Laravel Dusk

What if I need to build assets?

You can still save precious time even if you need to build your static assets in your CI scripts!

My favorite package for this is Airdrop (by Aaron Francis). It helps you build static assets only if they’ve changed between commits. If they have not changed, you can download them from a file system driver such as S3.