The One Tool You Can't Afford to Skip

Mon, 26 May 2025 - 5 min read
A brick wall, symbolising the strong foundation with a tool like ESLint

The One Tool You Can’t Afford to Skip (Hint: It’s Not a Framework)

Imagine you’re building a house. You’ve got the blueprints, the materials, and a great team. But what if one person uses a different kind of nail for every board, another forgets to secure a few beams, and a third decides to randomly change the window sizes? The house would be a mess. It might even fall apart.

This is what happens to codebases without a consistent set of rules. For junior developers, getting your code to “work” is the first milestone. But writing code that’s maintainable, readable, and consistent is the next, and arguably more important, step. This is where ESLint comes in.

Why ESLint is Non-Negotiable

Some people see ESLint as optional, a “nice-to-have” tool they’ll add later. But for me, it’s the very first dependency I install on any new project. Why? Because it’s a productivity superpower that forces consistency and saves you from a ton of future headaches. ESLint isn’t just about forcing you to use semicolons or tabs. It’s a powerful linter that catches subtle bugs and ensures your code is predictable, which makes collaboration and future debugging infinitely easier.

Here’s what it gives you:

  • It catches bugs before you even run your code: Ever forgotten an await on an async function? Or declared a variable but never used it? ESLint will highlight these common mistakes right in your editor. This isn’t just a style check; it’s a bug-catching machine that prevents silent failures.
  • It stops endless style debates: Tabs vs. spaces, single vs. double quotes—these are debates no one wants to have. With ESLint, you set the rules once, and the tool enforces them for everyone. This frees up code review time to focus on what really matters: logic and architecture.
  • It makes you a better developer: By pointing out common antipatterns and inconsistencies, ESLint trains you to write cleaner, more robust code. Think of it as a mentor that’s always looking over your shoulder, gently correcting you.
  • It makes teamwork painless: When every developer on a team writes code that looks the same and follows the same rules, the codebase becomes one unified piece of work, not a collection of different styles. It makes the team work and think more closely, aligning everyone toward a single, cohesive end goal.

A Real-World Example: JS to TS Migration

I strongly advocated for my team to set up a robust ESLint foundation before we started a large-scale migration from JavaScript to TypeScript. Other teams on decided to skip this step, opting to dive straight into the migration. They saw it as an unnecessary delay.

Within a few weeks, the difference was night and day.

While our team was moving smoothly, theirs was getting bogged down by technical debt. Their new TypeScript code was filled with inconsistent formatting, forgotten imports, and subtle type-related errors that ESLint would have caught automatically. Every time they thought they were making progress, they’d have to stop and fix a pile of newly created inconsistencies. On top of that they were working on a more custom rules than what was agreed across all FE teams, which was difficult to keep up with and generated even more technical dept.

Because I insisted on a solid ESLint setup first, our team was able to focus on the migration itself. Our code reviews were cleaner, our commits were smaller, and the new codebase was consistent from day one. We shipped features faster and with fewer bugs in parallel with the migration because the tool was doing the tedious work for us. The other teams eventually had to stop and implement ESLint to clean up their mess, losing valuable time and momentum in the process.

This experience solidified my belief: ESLint isn’t an option. It’s a prerequisite for any healthy, productive codebase.

Your First ESLint Setup

Ready to get started? Here’s the simplest way to add ESLint to your project:

  1. Run the setup command:
    npm init @eslint/config@latest
  2. Follow the prompts: The CLI wizard will guide you through choosing your framework (like React or Vue), language (JavaScript/TypeScript), and style guide.
  3. Integrate it into your workflow: Set up your code editor to automatically fix issues on save. For an even more robust setup, add a pre-commit hook with a tool like Husky to prevent any code that fails the linting rules from ever making it into your codebase.

Once it’s set up, you can stop thinking about it. ESLint will just be there, quietly working in the background, keeping your codebase healthy and consistent.

Conclusion

I install ESLint on every project even for very small ones, it just keeps my code consistent.

The difference between a junior developer and a senior developer isn’t just about knowing more frameworks. It’s about building a solid foundation for your code. ESLint is that foundation.

Don’t treat it as an afterthought. Make it the very first tool you add to your development toolbox. It’s the most powerful investment you can make in the long-term health of your project and, more importantly, in your own growth as a developer.

Join my newsletter

Subscribe to get updates on new blog posts, useful frontend tips and ideas you can apply in your own work.