babel don’t require a master, or constant support, if they are used simply.
2ish years ago I replaced my team’s awful
grunt setup with
npm scripts. It took less than 2 weeks, mostly spent wondering what various
grunt plugins were doing (or not) in our previous setup. From scratch, it might have been 4 days altogether. Since then, we haven’t had to touch anything, except to update dependencies. If we ever start a new project, we could use everything basically as-is.
The key difference is the old system had tons of plugins, bridges, and interdependencies, each with unique config, releases, and docs (usually poor, often non-existent). That kind of set-up does require a master, and constant vigilance. Our current system uses
webpack only handles js/ts compilation and bundling. Utilizing build tools independently means we almost exclusively use core behavior, with minimal configs and fantastic docs, and we can update or replace a tool at will with zero collateral damage.
For anyone who’s curious:
tsc (~ 25 line config file) - type-checking only
webpack (~25 lines of basic config) -
babel-loader is the only loader, zero or one plugin(s). Our config also has ~90 lines of app-specific bundle-splitting (including our only plugin), but that’s due to how we serve the code, which is a special case.
babel (~12 line config file) - compilation of all code, using
typescript presets with no other plugins.
eslint (~25 lines of basic config) - Handful of plugins as you wish. (uses
babel for parsing) Our config is much bigger because we hardcode a ton of code style rules, but the default presets are pretty good.
jest (~40 line config file) - uses
babel under the hood, but it includes
less (0 lines of config) - Not necessarily recommending, but it works fine. Use whatever your favorite CSS tool is.
node (maybe ~50 lines of JS total?) - a few short JS scripts for things like cleaning your output folder and moving static resources. We use a couple low-level file management packages.
- Then just call them as needed in trivial
npm scripts. We use a couple simple packages to run scripts in parallel, but you might not need them. (e.g.
npm run dev simultaneously calls
npm run type-check,
npm run build:code,
npm run build:css, etc.)
If you don’t use TypeScript, this setup is even simpler; I imagine Rescript would add about the same amount of plugins and settings as TS does. (I haven’t had a chance to give Rescript a proper go yet.)