Build Tools

Table of Contents


*R → - Personal Recommendattion/ Opinion
*O → - Alternative Option - Pick this or purple
*A → - Order in roadmap not strict (Learn anytime)
*X → - I wouldn't recommend

Task Runners

Task Runners:

  • [X] *R → npm scripts
  • [ ] *X → Gulp

NPM Scripts1

The "scripts" property of your package.json file supports a number of build-in scripts and theri preset life cycle events as well as arbitrary scripts.

There all can be executed by running npm run-script <stage> or npm run <stage> for short, pre and post commands with matching names will be run for those as well (e.g. premyscript, myscript, postmyscript ).

Scripts form dependencies can be run with npm explore <pkg> -- npm run <stage> .

1: {
2:   "scripts": {
3:     "precompress": "{{ executes BEFORE the `compress` script }}",
4:     "compress": "{{ run command to compress files }}",
5:     "postcompress": "{{ executes AFTER `compress` script }}"
6:   }
7: }

Module Bundlers

Module Bundlers:

  • [X] *R → Webpack
  • [ ] *O → Rollup
  • [ ] *O → Parcel


Readmore about Webpack .

Linters and Formatters

Linters and Formatters:

  • [X] *A → Prettier
  • [X] *A → ESLint
  • [ ] *X → StandardJS



Prettier is an opinionated code formatter. It enforces a consistent style by parsing your code and re-printing it with its own rules that take the maximum line length into account, wrapping code when necessary.

Pretter vs. Linters

How does it compare to ESLint/TSLint/stylelint, etc.?

Linters have two categories of rules:

1.Formatting rules

e.g: max-len, no-mixed-spaces-and-tabs, keyword-spacing, comma-style…

Prettier alleviates the need for this whole category of rules! Prettier is going to reprint the entire program from scratch in a consistent way, so it's not possible for the programmer to make a mistake there anymore.

2.Code-quality rules

e.g: no-unused-vars, no-extra-bind, no-implicit-globals, prefer-promise-reject-errors…

Prettier does nothing to help with those kind of rules. They are also the most important ones provided by linters as they are likely to catch real bugs with your code!

In other words, use Prettier for formatting and Linters for catching bugs!


First, install Prettier locally:

1: npm install --save-dev --save-exact prettier

Then, create an empty config file to let editors and other tooling know you are using Prettier:

1: echo {}> .pretterrc.json

Next, create a .prettierignore file to let the Prettier CLI and editors know which files to not format. Here's an example:

1: # Ignore artifacts:
2: build
3: coverage

Now, format all files with Prettier:

1: npx prettier --write .
`npx` ships with `npm` and lets you run locally installed tools.

prettier --write . is great for formatting everything, but for a big project it might take a litter while. You may run:

  • prettier --write app/ to format a certain directory, or
  • prettier --write app/components/Button.js to format a certain file, or
  • use a glob like prettier --write "app/**/*.test.js" to format all tests in a directory (see fast-glob for supported glob syntax).

If you have a CI setup, run the following as part of it to make sure that everyone runs Prettier. This avoids merge conflicts and other collabortion issues!

1: prettier --check .

--check is like --write, but only checks that files are already formatted, rather than overwriting them.

Set up your editor

See Editor Integration for how to set up your editor. If your editor does not support Prettier, you can instead run Prettier with a file watcher.

ESLint (and other linters)

If you use ESLint, install eslint-config-prettier to make ESLint and Prettier play nice with each other. It turns off all ESLint rules that are unnecessary or might conflict with Prettier.


List some frequent configurations:

Default CLI Override API Override Description
80 --print-width <int> printWidth: <int> Specify the line length that the printer will wrap on.
2 --tab-width <int> tabWidth: <int> Specify the number of spaces per indentation-level.
false --use-tabs useTabs: <bool> Indent lines with tabs instead of spaces.
true --no-semi semi: <bool> Print semicolons at the ends of statements.
false --single-quote singleQuote: <bool> Use single quotes instead of double quotes.
true --no-bracket-spacing bracketSpacing: <bool> Print spaces between in object literals.



ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code, with the goal of making code more consistent and avoiding bugs.

  • ESLint uses Espree for JavaScript parsing;
  • ESLint uses an AST to evaluate patterns in code;
  • ESLint is completely pluggable, every single rule is a plugin and you can add more at runtime.


First, you can install ESLint using npm:

1: npm install eslint --save-dev

Then, you should set up a configuration file:

1: ./node_modules/.bin/eslint --init
2: # or
3: npx eslint --init

After that, you can run ESLint on any file or directory like this:

1: npx eslint yourfile.js

It is also possible to install ESLint globally rather than locally (using npm install eslint --global ).

*! However, any plugins or shareable configs that you use must be installed locally in either case.


There are two primary ways to configure ESLint:

1.Configuration Comments

Use JavaScript comments to embed configuration information directly into a file.

2.Configuration Files

Use a JavaScript, JSON or YAML file to specify configuration information for an entire directory and all of its subdirectories. This can be in the form of an .eslintrc.* file or an eslintConfig field in a package.json file, both of which ESLint will look for and read automatically, or you can specify a configuration file on the command line.

Command Line Interface


Date: 2020-12-08 Tue 17:42

Author: Jack Liu

Created: 2021-01-01 Fri 14:34