This post is an update to a previous post: Our Baseline Gulp Build Process. We haven't changed the process itself very much since then, but we have updated the way we initialize it on a new site (or a site new to us).
We've moved the Gulp tasks into an NPM package fm-site-build with a new Github repo. Having the Gulp tasks contained in an NPM package makes "deployment" of updates a lot easier. Instead of having to copy various files with the changes into a site, we can now update the fm-site-build version in the site's `package.json` and run `npm install`.
It is inevitable that the Gulp tasks will need updates. Earlier this week we found an issue with the Google Font url import statement not being the first line in the production CSS build file. We fixed the issue, added a config option and bumped the package version.
The NPM package code does some kind of odd things to get Gulp streams into an NPM package. But it seems like a good, working solution for more traditional website builds. Making the leap to Webpack for these kinds of sites can be overkill.
Once you have used Webpack, it is hard to use anything else. Everything else seems clunky. But for us right now, it's a better fit for the projects that lean more towards web applications. It requires a pretty significant change in thinking. Loading CSS via a require or import statement in a Javascript file is different than how things have been done for the past however-many-years since the Internet was born. Webpack eases development of Javascript-heavy sites, but JS modules require (heh) some relearning of how to structure js. With every advancement, comes more layers of complexity.
As always, our thinking on this may change as we try to balance our blend of web technologies. We want to incorporate new advancements, the things that will make testing easier or our code cleaner. These changes translate into fewer things breaking and less maintenance time. But we also want to avoid new things that will have a short-shelf life.
Posted in #Technologies