Amey-Thakur JS tooling selection
The JavaScript tooling landscape churns constantly, but the decisions are stable: pick tools by what the project is (app, library, monorepo) and let speed and defaults settle the rest. Chasing every new tool costs more than the tools save.
Method
- Choose the bundler/build by project type. A web app: Vite (fast dev server, sensible defaults) is the modern default. A library: tsup or unbuild (dual-format output, types, minimal config; see npm-publishing). A backend: often no bundler (run TypeScript directly with tsx, or compile with tsc/tsup for prod; see node-backend-setup). Match the tool to the artifact, not to the trend.
- Let esbuild/SWC-based speed be the baseline. Modern tools transpile with esbuild or SWC (Rust/Go-fast) rather than Babel; dev feedback in milliseconds is now the floor. If your toolchain has slow dev reloads, that alone can justify a migration.
- Pick one linter/formatter stack and stop debating it. Biome (fast, lint+format in one, minimal config) or ESLint + Prettier (mature, huge plugin ecosystem, the incumbent). Both are fine; consistency and enforcement (see linting-setup, style-guides) matter far more than which. Enable the type-aware rules that catch real bugs (no-floating-promises, exhaustiveness).
- Choose the test runner to match the build. Vitest for Vite projects (shared config, fast, Jest-compatible API); Jest where it is entrenched and working; the Node built-in test runner for dependency-light backends. Do not run a test runner whose module handling fights your bundler's (see testing-strategy).
- Weigh migrations by real payoff, not novelty. A working toolchain has value; replace it when the new tool fixes a felt pain (slow builds, config sprawl, a capability gap), not because it trended. Estimate the migration cost (config, CI, every developer's setup) against the benefit honestly (see rewrite-vs-refactor).
- Prefer fewer tools with good defaults over a bespoke pipeline. Every tool is a dependency to update, a config to maintain, and a thing new contributors must learn (see onboarding-docs). An all-in-one (Vite + Vitest + Biome) beats a hand-assembled ten-plugin chain for most projects.
Boundaries
- Tooling choice does not change your code's correctness; it changes developer velocity and build output. Do not let a tooling migration masquerade as product progress.
- The specific winners shift year to year; the selection method (by project type, by felt pain, favor speed and defaults) is what remains stable. Re-check the current landscape when starting fresh.
- Framework meta-tools (Next, Remix, Nuxt, Astro) bundle these choices for you; when using one, adopt its toolchain rather than fighting it.