I think we’re often guilty of assuming that because our tools are great solutions for some things, they’re automatically the solution for everything.
I still find the landscape of build tools completely overwhelming, but I found this distinction to be a useful way of categorising the different kinds of build tools:
Build tools do two things:
- Install things
- Do things
So bower, npm and yarn install things, whereas grunt, gulp, and webpack do things.
This is a “what if?” scenario, but it’s all too plausible.
For site owners, the (partial) solution is to have a strong Content Security Policy.
(In the wake of Spectre and Meltdown, this is now a perfectly legitimate action for security-conscious web users to take; I hope your site can support that.)
For a small to medium sized project, this sounds like a sensible way to approach build tasks. It feels nice and close to the metal.
Speaking as an ancient web developer myself, this account by Gina of her journey into Node.js is really insightful. But I can’t help but get exhausted just contemplating the yak-shaving involved in the tooling set-up:
The sheer number of tools and plugins and packages and dependencies and editor setup and build configurations required to do it “the right way” is enough to stall you before you even get started.
Not to sound all “Get off my lawn, kids!” but I think there might be something to this. When you’re requiring hundreds of dependencies to do little tasks that you should be able to code yourself, something’s not right.
But, for the love of all that is programming, write your own bloody basic programming functions. Taking on dependencies for these one-liners is just nuts.
That said, you don’t want reinvent hundreds of wheels either (as most of the comments point out). There’s a balance to be had.