Six opinions about developer tooling that get pushback in code review and are still right. Each one comes with the reasoning, so you can disagree with the argument rather than the conclusion.
A hand-tuned ESLint config accumulates rules nobody remembers enabling, disagrees with the formatter, and produces a warning stream everyone has learned to scroll past. Adopt a single opinionated preset, run a formatter separately, and spend the argument budget on something a user will notice. Configuration is a cost you pay on every upgrade forever.
Filesystem I/O across the virtualisation boundary is the bottleneck, and it is why npm install or a test suite touching thousands of files runs noticeably slower in a container on a Mac than natively. Containers are the right answer for CI and production parity of dependencies like Postgres and Redis. Running your own application code in one, on a laptop, usually buys parity you did not need at a speed penalty you feel all day.
Adding strict: true to a mature codebase means thousands of errors and a migration that stalls at 60%, leaving you with two dialects in one repo. Enabling it on day one costs a few hours of learning. The middle path — non-strict TypeScript — gives you the syntax overhead of types with weak guarantees, which is the worst position on the curve.
A failing snapshot asks a question nobody can answer: is this change intended? The reflex is --update-snapshots, at which point the tests assert only that the code does what the code does. Assert on the specific behaviour you care about — the rendered heading, the accessible name, the emitted event — and keep snapshots for genuinely stable serialised output.
Bash is excellent glue for a dozen lines. Beyond that you are hand-rolling argument parsing, error handling and data structures in a language with no types, surprising word-splitting rules and no test framework. The rewrite takes an afternoon and removes a class of failure that silently continues after an error because someone forgot set -euo pipefail.
Nx, Turborepo and friends solve real problems: task graphs, remote caching, affected-project detection at a scale where a full CI run is unaffordable. With four packages, a workspace and a Makefile do the same job with no build-graph configuration to debug. Adopt the tooling when the CI time it saves exceeds the time it costs — and measure that rather than guessing.
Test coverage percentage is a metric worth tracking and never worth targeting. Coverage tells you which lines never ran; it says nothing about whether the assertions are meaningful. A mandated 80% threshold reliably produces tests that call functions and assert nothing, which is worse than no test because it looks like protection.