Code linting and formatting and Prettier?

[msimerson]

For years now, the Haraka project has had automated code formatting and linting via eslint. We configure eslint with local .eslintrc files within each package, and the bulk of the configs coming from a shared eslint-plugin-haraka package, which in turn also shares from eslint:recommended.

Code linting and formatting happen locally on the developers machine when they run npm run lint, 'npm run lintfix', and also automatically every time a PR is opened or pushed to the GitHub repo via the lint GHA workflow I've set up.

The world is changing on us. eslint is exiting the formatting game and will focus solely on linting. To get us ready for that future, I have modified our haraka-eslint package and removed all the deprecated formatting rules. To minimize any potential disruption, and to conform with current eslint standards, the updated package is now published as @haraka/eslint-config. This newer config adds the Haraka globals and similar configs that can be removed from each package when they are updated.

For plenty of reasons (particularly, the hair on the heads of our developers and maintainers), we will need to choose a new code formatter. There's a variety to choose from but Prettier is the 900# gorilla in this space.

Prettier Pros

• offers almost no configuration.
• almost no config = almost no bike shedding = more time for coding
• it's very easy to automate workflows around it.
• pretties javascript, markdown, yaml, and more
• our code looks like everyone else's (++ readability ++)

Prettier Cons

• offers almost no configuration
• cuddled elses

[msimerson]

Lint Best Practices

Lately I've taken to changing the lint config in package.json to look like this:

"scripts": {
    "lint": "npx eslint@^8 *.js test",
    "lint:fix": "npx eslint@^8 *.js test --fix",
}
"devDependencies": {
    "@haraka/eslint-config": "^1.1.2",
    "haraka-test-fixtures": "^1.3.4"
}

I've also been removing eslint from the devDependencies section of package.json. Reasons why (add your own considerations):

• I have eslint installed via a package manager on my laptop.
  • npx eslint ... uses the installed version when it satisfies the version requirement
  • package managers install much faster than npm -g eslint
  • package managers have built-in tools for keeping installed packages up-to-date
  • if eslint is not installed globally, the user is prompted to install it locally (within the checkout)
• eslint has 82 dependencies
  • in a tree of 50 haraka repos, a global eslint avoids 82*50=4,100 installs, and thousands more reinstalls
• it's a better default, of NOT installing dev dependencies
  • I'd wager most production haraka installs don't npm install --production (v2) or npm install --only=prod (v6) or npm install --omit=dev (current) to avoid installing the development dependencies.
• the CI tests use the lint script to automatically install eslint
• it avoids nearly useless alerts from [greenkeeper|dependabot|synk] about new versions of eslint
• I haven't seen any downsides to this...yet.

We used to list eslint=*, but over time as the tool evolved and major version were released, our test suites broke. The npx syntax above is comparable to using eslint=^8.0.0, which has worked well for quite a few years.