View profile

Right-Sizing Automated Best Practices

Right-Sizing Automated Best Practices
By Mastering JS Weekly • Issue #79 • View online
Addy Osmani once said that “best practices should be automated as much as possible.” This idea is largely unquestioned in the developer community: more automated code checks is always better. However, I think that the issue of automated best practices is more nuanced.

Should they, though?
Should they, though?
Is this too much?
Is this too much?
What Should Block the Build?
Earlier this week, I was cleaning up some build failures on Temporal’s TypeScript SDK samples. The build was failing because of a Prettier formatting issue in the .vscode folder. That hid a few other linter issues that were caused by adding a new rule after the Prettier formatting issue was introduced. All in all, took 5 commits to clean up the build.
Not a good use of time
Not a good use of time
Now this case wasn’t particularly bad, but what happens in a CI/CD situation where a broken build means you can’t deploy to production? Do you delay shipping a critical bug fix because of a formatting issue in a README?
The downside of automated code checks is that they escalate minor issues into critical blocking issues.
Code Formatters (e.g. Prettier) In CI
We strongly advise against using Prettier in CI and failing builds due to formatting issues. Formatters are a cut and dried case of escalating trivial issues into critical issues. At most, formatting issues should be a warning in your automated tests.
This is especially important for open source projects, because not all potential contributors have your preferred tooling setup. Many contributors just edit from GitHub’s UI, which doesn’t have any automated formatting.
There's always "that guy" who nitpicks open source PRs and drives away contribs
There's always "that guy" who nitpicks open source PRs and drives away contribs
We’re not saying that formatting issues shouldn’t be fixed. But formatting issues also shouldn’t block releasing. At the very least, you should make an automated GitHub action that fixes formatting, rather than blocking on the developer fixing formatting themselves.
Linters (ESLint)
Linters are more nuanced. On one hand, they can help catch glaring errors, like undefined variables or assignments to `const` variables. But, on the other hand, linters often enforce formatting rules, like spaces before function parentheses or end-of-file newlines.
How many times has your build been broken because of a missing EOF newline?
How many times has your build been broken because of a missing EOF newline?
We recommend using ESLint’s “warn” setting for purely stylistic issues. Especially since ESLint’s `–fix` fixes warnings as well as errors. What is a purely stylistic issue is open to some interpretation. There are clear cases of stylistic issues, like space-before-function-paren. And clear cases of functional issues, like no-undef. But issues like semicolons or end of file newlines can be considered functional or stylistic depending on use case.
Regardless, the takeaway from this newsletter should be to carefully consider which best practices are worth enforcing automatically, versus which just create meaningless busy work and escalate trivial issues. Any issue that breaks your build is a critical and urgent issue. Make sure that your team doesn’t get burned out by fixing “critical” issues that are just a case of an extra space between `function` and `()`.
Most Recent Tutorials
How to Check if a Variable is an Integer in JavaScript - Mastering JS
Handle POST Form Data with Express JS - Mastering JS
Check What Arguments a Sinon Stub Was Called With - Mastering JS
What We're Reading
Release v4.3.0 · mongodb/node-mongodb-native · GitHub
Critical Resources and the First 14 KB - A Review | Tune The Web
What NPM Should Do Today To Stop A New Colors Attack Tomorrow Posted on Monday, January 10, 2022.
Did you enjoy this issue?
Mastering JS Weekly

Pragmatic web development. No bloatware allowed!

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue