Set up linter rules

[nickbabcock]

Set up linter rules

[nickbabcock]

I assume the following would be a reasonable start.

{
  "extends": ["eslint:recommended", "plugin:node/recommended", "prettier"]
}

Probably tucked inside eslintConfig field in a package.json so we don't need to clutter the root directory any more than it needs to be.

Maybe there is some way we can have this config without needing to add eslint-config-prettier, eslint-plugin-node, eslint and to the package.json (and package-lock.json). I'd rather just have the latest version of those dependencies ran every time I wanted to lint instead of some pinned version.

[soryy708]

Extending the recommended is reasonable, but it doesn't cover many very useful checks. Also, the "recommended" may be working on a style that's different from the existing convention here.

To set up the latest version instead of some pinned version, just use the >={version} rule in package.json instead of ={version}

The linter configuration can be quite long, especially if you add a lot of plugins.
From what I've seen so far, looks like the common practice is to put it in its own file (.eslintrc) as opposed to in package.json.

Why do you care about cluttering the root directory? You can #26 if you're concerned about what happens when the package is npm installed.

Technically you can run a linter without any configuration per-project, so it runs with your personal global preferences. However, if you do it that way:

1. You're not sharing it with other developers
2. Other developers may have different preferences
3. The linting can't happen as part of CI/CD

[soryy708]

If we go with eslint, we'll obviously have to use eslint configuration.

I'm reading the docs for eslint-plugin-node and it looks like a lot of these rules are already covered by the basic eslint. Which rules in particular do you want?

I'm reading the docs for eslint-plugin-prettier and it looks like a lot of rules are also already covered by the basic eslint, and some may conflict. Which rules in particular do you want?

In my personal projects, I go with just eslint and eslint-plugin-import, and it covers most use-cases very nicely.

[soryy708]

I've implemented an .eslintrc (see pull request).
Here are a few issues I'd like to bring up for discussion:

• Which ecmaVersion are we targeting? Is this supposed to be run in a browser? or in a node environment? How far back to we provide backwards compatibility?
• no-prototype-builtins is part of eslint:recommended, but turning it on flags existing code as an error (specifically various calls to .hasOwnProperty()). Do we want to keep the rule off? or do we turn the rule on and fix the existing code?
• The comparison operator (==) may do implicit type coercion, but the strict comparison operator (===) doesn't do that. There are various instances of using == in the existing code when === could have been used. There's an option to turn on a rule to enforce that (eqeqeq).
• Do we care about magic numbers in the existing code? (no-magic-numbers)
• var declarations imply hoisting. There's a rule that enforces putting them on the top of the scope, so that the implied hoisting is communicated. (vars-on-top)
• var can be replaced with const or let in newer versions of JS. Do we want to enforce that? (no-var)
• Arrow callbacks are more concise and intuitive in terms of scope (e.g. this keyword semantics). Do we want to replace function(){}s with ()=>{}s where possible? (prefer-arrow-callback)

[nickbabcock]

I'm happy to accept PRs that updates code to conform to some eslint rule, but as of now I have yet to see a solution that minimizes the amount of cruft that is added to the project. Any solution would need to be less than a half dozen lines.