Thoughts on using ESLint for static analysis

[pmdartus]

@pimterry I wanted to get your thoughts on using ESLint to enforce static analysis against the Mockttp source code. I see value in adding static analysis for a project of this scale for the following reasons:

• catching silly mistakes like https://github.com/httptoolkit/mockttp/pull/123
• enforcing best practices like removing unused imports or enforcing usage const over let when possible
• enabling external developers to contribute to this project by enforcing a code quality standard.

The ESLint adoption can be done gradually by enforcing rules incrementally until reaching a state where you are happy without having to be a maintenance burden in the long run. For what it's worth, create a quick POC, enabling ESLint with the eslint:recommended config and using eslint --fix to automatically fix the "fixable" linting errors.

I am certainly biased on this, so I don't this to be a limiting factor for you to quickly iterate over this project.

[pimterry]

I'm open to it, but I'm cautious.

I've found on other projects at previous jobs that it's easy to set up linting in a way that continually interrupts your workflow, with most interruptions not providing any real value.

I'm not really concerned about things like unused imports, using let unnecessarily, dangling semicolons, etc. It's good to tidy up such things when you see them, sure, but none of that is causing any real problems, and personally I don't want to that to interrupt me from whatever I'm actively trying to do (by CI errors, by git hooks while committing, or by extra noise while iterating+testing locally). I'd rather not actively fix similar non-functional issues en masse either without good reason, since it adds noise to the git history.

Async describe is a good example of the other side of this though, since that does indeed always fall into the category of impactful things to definitely fix.

Up to you. If you're keen, I'm open to trying out linting here, with some limited setup that only checks for things that are definitely substantial mistakes and/or real functional issues.