I saw you can use NPM instead of Yarn so I chose to go that route, instead of setting up and learning a whole new workflow tool. I now want to deploy, and need to compile for production so I can commit all the necessary bits to git and push. What is the equivalent of yarn build:production if I am in NPM?
It’s a package script, so you’d use the
npm run-script build:production
npm run build:production
Thanks. Upon doing that, I see it dropped the distilled files down into /dist/scripts and /dist/styles.
But /dist is gitignored. Why?
I also note that git doesn’t see any other changes, either. Where are these files called from? What else do I need to grab?
dist/ directory is ignored by VCS (
npm), but rather what deployment model is used. In this case the packaging + release is done together with deployment. The npm script builds the app and emits the resulting build artifacts into
During deployment of the site (app), first the app source code is pulled by the deployment target (usually a Trellis server pulls from a publicly accessible git repo (like on GitHub, or a private GitLab instance, or even through a SSH tunnel/VPN from the deploying workstation)) and then the build artifacts are transferred separately to it, usually using
rsync. The deploy hooks shipped with Trellis (and which can be enabled) do exactly this.
Then there is the other deployment model, which would consist of using “dirty commits” where the build artifacts are committed as source code and are pulled with the rest of the git repo.
The build process builds assets, it doesn’t deploy them. The Roots stack is built on a philosophy that treats the files in your repo as the minimal source from which a full site is built–this is the same reason the
vendor directory is ignored by git. The intent is that your build process (i.e.
npm run build:production) is distinct from your deploy process. Sage is concerned only with the theme and its assets, so it includes only the build process, not the deploy process. @strarsis has mentioned a couple of deployment options.
Thanks for the explanation. I want to understand the philosophy this is created from, so I’m not cutting across the grain (and maybe I can up my skills). What you describe as “dirty commits” is what I normally do in other things. Calling them “dirty” makes it seem that this is a non-optimal solution. Is that because it’s “wrong” to commit output? I know C coders don’t like to put binaries into their repos. You describe using Trellis, or rsync to pull the output separately. So it’s not like we’re recreating it on the other end (like vendors/ gets recreated), just transporting it separately. Why?