Version control strategy for webpack-encore project

Question

I'm learning to use webpack-encore and noticed it is installed only as a dev dependency. Does that mean I should compile my js and css files on development and push them to the repository, and then to production?

That seems to me what the docs are implying, but wouldn't that mean a merge-conflict hell? Compiled files would be impossible to merge.

Also wouldn't that be contrary to version control philosophy? As far as I know, you don't publish binaries in compiled languages (ie C/C++), you push the code and expect the server to compile them. I know this isn't the same type of "compilation" in javascript, but what is the expected behavior of the production server in this case? To receive the files ready to serve them, or to compile them at the time of release?

Thanks in advance

Answer 1

Does that mean I should compile my js and css files on development and push them to the repository, and then to production?

Not exactly - it depends on how you deploy.

When you deploy, you need to run ./node_modules/.bin/encore production to build your assets. Once you've done this, only your built assets (eg web/build ) need to be transferred to production.

You could run this command locally (or on some "build" server) and the transfer all the files to production. Or, you could use a git pull on production, and then run this command on production (the downside being that you would need Node.js installed on production).

You shouldn't / don't need to commit your built files to your repository. But... if it simplifies your deploy (ie you want to do a git pull and be done), there's no real problem with that.

I just added a PR to answer these in the FAQ ( http://symfony.com/doc/current/frontend/encore/faq.html ) - here's the PR until it's deployed: https://github.com/symfony/symfony-docs/pull/8109

Cheers!

Answer 2

Solution 1:

1. Run yarn run encore production locally
2. Check out which files have been created / modified
3. Add them to VCS
4. Commit
5. Push / deploy

Solution 2:

1. Push / deploy
2. Run yarn run encore production remotely during deployment

To my eyes the 2nd solution is way better, because you don't need an extra human-checking before deployment, everything is automated. But this has a strong drawback: building assets can be a slow process, and when I deploy, my production is down during 5 to 20 seconds until assets are built.

Here's the HTTP 500 error:

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

It looks like the manifest.json file is deleted at the beginning of the process, and created from scratch later on.

Something that should be improved?