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.
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:
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.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.
Ready to get started? Here’s the simplest way to add ESLint to your project:
npm init @eslint/config@latest
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.
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.
Subscribe to get updates on new blog posts, useful frontend tips and ideas you can apply in your own work.