What’s good enough?

Starting any new project is always difficult; whether it’s a small side project or the next ba-zillon dollar startup. Here’s my thoughts on which code quality checks should make it into your next Frontend project.

TL;DR

The following are guaranteed to add value and save pain in the longrun:

  1. Checking for lint
  2. Formatting code
  3. Checking your dependencies for vulnerabilities

Writing unit tests is a good investment, if the circumstances and codebase are right.

Checkout this example repo to see these in action.

ESLint

ESLint is a static code analysis tool used to find, and sometimes automagically fix your code smell. You can use it in your IDE and CI/CD pipeline to keep your code cleaner.

Getting started is easy, and will save time & pain should you choice to enforce rules at a later date.

Once installed and configured you can set up an NPM script (this example assumes your source is in src and you’re using JavaScript - not TypeScript)

{
    "lint": "./node_modules/.bin/eslint --max-warnings=0 --ext=js src"
}

Now running npm run lint from your project will run the ESLint static code analysis against your code to catch lint, and hopefully reduce bugs.

ESLint will attempt to fix any errors it encounters using this NPM script:

{
    "lint-fix": "./node_modules/.bin/eslint --max-warnings=0 --fix --ext=js src"
}

Prettier

No your code is bug free (lolz), it’s time to look at code formatting. Consistent code formatting in your project will help reduce effort; for you and other contributors.

Formatting isn’t linting. See: Prettier vs. Linters

Install Prettier into your project, and use the pre-made config: eslint-config-prettier to integrate Prettier with ESLint.

Similar with ESLint in the section above, we’ll create 2 npm scripts for running, and fixing formatting issues:

{
    "prettier-lint": "npm run prettier && npm run lint",
    "prettier-lint-fix": "npm run prettier-fix && npm run lint-fix"
}

You can also combine ESLint and Prettier into a single NPM scripts. All of the NPM scripts look like this:

{
    "lint": "./node_modules/.bin/eslint --max-warnings=0 --ext=js src",
    "lint-fix": "./node_modules/.bin/eslint --max-warnings=0 --fix --ext=js src",
    "prettier": "./node_modules/.bin/prettier --check ./src/",
    "prettier-fix": "./node_modules/.bin/prettier --write ./src/",
    "prettier-lint": "npm run prettier && npm run lint",
    "prettier-lint-fix": "npm run prettier-fix && npm run lint-fix"
}

Jest

“Unit tests are a waste of time” by All developers under pressure

Unit testing is time-consuming, and can add little value if you have a poorly designed codebase. Skipping unit testing might be the right thing to do, but you’ll have to trade code quality in return.

Should you decide to write unit tests (which you should), then Jest is great framework to get you going.

NPM Audit

The NPM eco-system is rich and really helps speed up development, but do you know what vulnerabilities are in the packages you’re using? Well, you should.

There’s a bunch of vulnerability scanning tools out there, some are free - others are eye-wateringly expensive.

Luckily, NPM has an in-built tooling to help with this.

When you run npm i on a project you’ll get a summary of known vulnerabilities, and their associated criticality:

npm i audit result

You can also run npm audit to generate a vulnerability report of the packages installed with your project.

Keeping up-to-date with the latest versions of packages is an essential housekeeping task. Neglect patching your packages, and you might fall foul to a hack.

Check out these posts if you’re interested in automating these checks with CI/CD: