JavaScript DevOps - Cheatsheet, Notes, Misc.

Enforcing coding standards

The usual way to enforce coding standards, such as how to use JSDoc commenting, is through a linting extension, such as eslint for JS, or tslint for TypeScript. These extensions are configurable, so you can tell it what to look for and how strict it should be.

Helpful links:

However, note that if these are installed as "extensions" they only enforce rules for yourself and devs that have it installed. If you are trying to enforce standards across many devs, across a repo, you might want to make the linter a dependency and then have it run as a build step and/or git hook.

TSLint vs ESLint

Based on what Palantir has publicly said, everyone should try to use ESLint over TSLint moving forward.

ESlint has also made it clear that this will be the way forward for TypeScript.

TSLint notes:

Overriding rules:

See: rule-flags docs.

  • Temporarily disable on next line:

    • /* tslint:disable-next-line */

      • Or
    • // @ts-ignore
  • Disable rule

    • /* tslint:disable:{rule} */

ESLint notes:

Config file

See Configuring ESLint for details.

Summary of options:

  • .eslintrc.*

    • .eslintrc.json (comments allowed)
    • .eslintrc.js (export config object)
    • .eslintrc.yaml | .eslintrc.yml
  • package.json -> eslintConfig: {}

Peer dependencies

A lot of eslint config packages require peer-dependencies that are not automatically installed when you do NPM install. For example, the eslint-config-airbnb needs a lot of peer dependencies to be manually installed, or else it will not work.

See my notes on NPM / node for details on auto-installing peer-dependencies.


  • Make sure typescript is installed locally (yarn add typescript --dev)
  • Add the parser (@typescript-eslint/parser) and the plugin (@typescript-eslint/eslint-plugin) dependencies

    • Update the ESlint config to use them:

      	"parser": "@typescript-eslint/parser",
      	"plugins": ["@typescript-eslint/eslint-plugin"]
  • You might need to explicitly add TypeScript as a language for ESlint to validate:

    • In .vscode/settings.json -> "eslint.validate": ["javascript", "javascriptreact", "typescript"]
  • If you want ESlint to recognize and read your TSConfig file, you might need to tweak some settings in your eslintrc config:

    • parserOptions: {"project": "./tsconfig.json"}
  • If you use import or exports, turn on module support:

    • parserOptions: {"sourceType": "module"}

If you get "Parsing error: ImportDeclaration should appear when the mode is ES6 and in the module context" error, first try making sure you have "sourceType" set to "module" under parserOptions (see this for details). If this doesn't fix it, it could be because you are importing a type out of a type definition file (e.g. @types/...), which the current parser + eslint can have a hard time handling. There are several issues around this, here and here.

Some extra guides:

Issues with plugins

This can be tricky to troubleshoot. If you are on version 6, you could always try pinning ES to version 5 - see this thead and this one.

Another thing to try is to make sure you are not mixing dependency locations - e.g. ESLint and all its plugins and dependencies need to be installed locally (through package.json) or globally (npm install -g), but not both. And with v6+, it looks like you should only install locally.

Another common issue is completely unrelated, but often throws errors about plugins - issues with a multi-root workspace - see below:

Multi-root workspace / monorepos

I recently had a heck of a time figuring out why ESLint was throwing all kinds of errors that didn't make sense - primarily the:

"Failed to load plugin 'vue' declared in 'frontend.eslintrc.js': Cannot find module 'eslint-plugin-vue'

That error actually had nothing to do with the plugin itself, but everything to do with the workspace file structure. I had what one might call a multi-root or monorepo structure, where major distinct projects (with separate node_modules and package.json) are in the same workspace. My structure looked like:

  • . (project root)

    • ./frontend
    • ./backend

It turns out for this kind of setup, running eslint against a file will work fine from the command line, but running from VSCode / extension will fail, because it doesn't understand the separation.

The solution is simple: the eslint.workingDirectories setting.

In {project-root}/.vscode/settings.json, I should have had:

	"eslint.workingDirectories": [

You can omit a directory if it is not configured for eslint. Or, if eslint is having trouble with imports, use changeProcessCWD (last resort):

	"eslint.workingDirectories": [
			"directory": "./frontend",
			"changeProcessCWD": true

Overriding rules

There are multiple ways to modify eslint rules.

Here is the full list of rules.

Modifying the actual config files

See this section about the difference between all the different config file types.

If you you just to turn a rule off, just set the key/pair value to "off".

	"rules": {
		"prefer-arrow-callbacks": "off"


If you just need to suppress the errors in a single spot or file, you can use inline comments.

For example, to disable / ignore for an entire file, you can put this at the top of the file:

/* eslint-disable */

Or, for a specific line, // eslint-disable-line or // eslint-disable-next-line.

You can also target specific rules:

// Example is function with too many params - violates `max-params` rule

// eslint-disable-next-line max-params
function tooManyParms(alpha, beta, charlie, delta, echo, foxtrot, golf) {

Prettier Notes

  • Actually getting Prettier to work

    • Make sure you have setup a config section (options below)

      • package.json -> prettier: {}
      • .prettierrc.json | .prettierrc.yml | .prettierrc.yaml
      • .prettierrc.js | .prettierrc.config.js

        • Must export object with config
      • .prettierrc.toml
    • Make sure you have IDE extension installed and enabled (at least for workspace)
    • Make sure you have dependencies installed

      • npm install --global prettier
      • yarn global add prettier
      • Or, manage with repo package.json file
  • Getting the linters to kick-in



Markdown Source Last Updated:
Thu Jan 23 2020 07:39:20 GMT+0000 (Coordinated Universal Time)
Markdown Source Created:
Wed Aug 21 2019 00:46:11 GMT+0000 (Coordinated Universal Time)