Warm tip: This article is reproduced from serverfault.com, please click

Run encore without blocking

发布于 2020-11-30 08:48:59

I have a Symfony project with a lot of scripts and styles. Encore takes about 4 minutes to execute in production:

npm run encore prod

It uses json-manifest-path for versioning. While it's executing though, I get a 500 response. The error is:

An exception has been thrown during the rendering of a template ("Asset manifest file "XXX/web/build/manifest.json" does not exist.").

This is because the cleanup:

Encore
    .setOutputPath('web/build/')
    .setPublicPath('/build')
    .createSharedEntry('app', './assets/js/app.js')
    .addStyleEntry('style', './assets/css/style.scss')
    // ... more assets here
    .enableSingleRuntimeChunk()
    .cleanupOutputBeforeBuild() // <------------------- cleanup
    .enableSourceMaps(!Encore.isProduction())
    .enableVersioning(Encore.isProduction())
    .enableSassLoader(function(options) {}, { resolveUrlLoader: false })
    .autoProvidejQuery()
;

How am I supposed to avoid this problem?

Questioner
Manolo
Viewed
0
yivi 2020-12-01 15:45:37

You are not supposed to run encore prod on your production machine (in the same way you are not supposed to run composer install in that machine).

Building & Deploying are different steps.

You'll need to run all the build steps in a different place (at the very least a different directory from the one you are using to actually serve the application), and then deploy the generated "artefact" (e.g. the result of your build process).

How you do this depends on your serving infrastructure and deployment process, but it can be something like:

  • copying the files (mv, cp, etc).
  • transferring the files from your build machine to your application server (rsync, scp, ftp, etc)
  • build a Docker application image and push to a container registry.
  • etc.

Whatever you do, you need to avoid running a long process that modifies files that are being actively served.

Build processes can be long and it's fine that they are long (as much as we'd prefer they'd be sorter), but deployment processes should as short as possible.