Do I really need a bundler?

For some reason I never really asked myself this question and just forged into the world of task runners like Gulp and Grunt — and bundlers like Rollup, Webpack, Parcel as I got going in web dev.

The abilities and advantages that these tools brought to the table were irresistible, and learning them also brought the benefit of fixing build system errors of projects that I forked or inherited.

How many out there have found themselves with the sudden challenge of managing Webpack config files after “ejecting” from a React application and realized that they were somewhat in over their head?

Having some understanding about how these tools generally work can save you from tooling nightmares.

However, as I found out in the last few days, I’ve been almost unquestioningly reaching out for these tools — all the while slowly de-automating tasks like image optimization and CSS prefixing and instead manually optimizing images with a tool like ImageOptim and being more careful about cross-browser compatibility while I write CSS.

To suggest abandoning build tools would rightfully be met with outcry. These tools are generally making the web better, and saving developers worlds of time.

But, if all you’re wanting to do is compile your SASS into CSS and transpile your ES6 javascript to browser-compatible Javascript — you may not need a bundler at all.

I dunno. you might?

If one or more of these following apply then you might need a bundler:

• You need your multiple asset types bundled and output to another directory.
• You want to transform, change, or optimize multiple assets and the dependency order matters.
• You are working with a large Javascript framework like React, Angular, or Svelte, and need to compile your JSX or other templating languages.
• You have several tasks you need run upon changing a file and want live previews in the browser.

Suffice it to say — there is a direct correlation between how many things you need done during the development and build process and the likelihood that you need a bundler.

Well, if it’s required by the framework you’re using, your professor, your masochism, or otherwise — then the answer is a resounding YES.

If none of those scenarios is the case and you just need to bundle some ES6 Modules and compile some SASS to an output file then maybe you’d be fine using NPM Scripts and a zero-config (this term is debatable) bundler like Parcel to automate your dev and build process.

I was taught in one of my first web development tutorials by Brad Schiff @learnwebcode all about using NPM Scripts to reference other NPM Scripts.

In concert with the NPM package npm-run-all, you can effectively configure your tasks to run in a series or in parallel by creating a scripts block in your package.json and then reference individual tasks in a command that chains them with npm-run-all.

“scripts”: {
  “dev-scripts”: “parcel watch src/js/main.js — out-dir assets/js/ — out-file bundle.js”,
  “dev-styles”: “sass — watch src/scss/main.scss:assets/css/bundle.css”,
  “dev-keystone-modules-styles”: “sass — watch src/scss/modules:assets/css/modules”,
  “dev”: “npm-run-all — parallel dev-scripts dev-styles dev-keystone-modules-styles”,
  “prod-scripts”: “parcel build src/js/main.js — out-dir assets/js/ — out-file bundle.js”,
  “prod-styles”: “sass src/scss/main.scss:assets/css/bundle.css — style=compressed”,
  “prod-keystone-modules-styles”: “sass src/scss/modules:assets/css/modules”,
  “prod”: “npm-run-all — parallel prod-scripts prod-styles prod-keystone-modules-styles”
}

For this particular project that happens to be a Wordpress theme I’m building, this was all I needed and is serving me just fine.

I am in no way suggesting you ditch all your fancy tools and return to the stone age, I just think that KISS principles should be considered with tooling and bundlers as they so often are with many aspects of web development and KISS seemed to do the trick for me this time around.

Keep killing it you little web assassins!

If you want to keep things bundler-free and still want live refresh, simply throw BrowserSync into the chain of scripts.

Follow the installation instructions in BrowserSync’s documentation, then add a script like this to your package.json:

“browser-refresh”: “browser-sync start --server --files 'css/*.css'",

Then add it to the chain of commands in your npm-run-all development script:

“dev”: “npm-run-all — parallel dev-scripts dev-styles dev-keystone-modules-styles browser-refresh”,

If you find that the page is reloading too soon, you might need to add a delay to the BrowserSync command.

At this point, it may be time to start considering at bundler though if you’re having issues with the order of execution of each task. I don’t, but it’s conceivable that you might.