Linting on a codebase has always been my weak point. I've always managed to get by usually by copy-pasting other people's configs, or that famous Airbnb config that I'm pretty sure not even Airbnb uses anymore. The problem, predictably, was that it just never worked for every single project I touched. Endless custom rules, hunting down obscure lint packages just to get that one thing I wanted done. It was another battle I fought endlessly.
That said, after a while, I noticed a pattern. I kept coming back to some core plugins again and again. Honestly, 90% of the time, I was building my lint config around these same few plugins. Maybe it’s because I've been sticking to the same tech stack for the past few months, or maybe those plugins are just genuinely solid. Personally, I think it's a mix of both.
Now, the second problem. I'd always just refer back to my old codebases to remind myself which plugins I needed and how to add them to my current config. It was fine, I was managing. But then ESLint 9 dropped. We're no longer using .json or old .js configs; they've completely switched to Flat Configs, defined in a totally different way. While this new linting system is more powerful, it meant I had to take my old, copy-pasted configs and completely rewrite them to fit the new Flat Config specs. One day, I just said, "Enough is enough."
That’s exactly when I decided to build Yae Lint Config. Truly, it's a tool I built for myself. The idea was simple: just run a command on the line, select the options I need for my lint config, and have the tool generate the file automatically. I've found it incredibly useful for every new project I've started. And trust me, it’s made config generation so much easier and way less time consuming. What used to be a tedious, copy-paste-and-rewrite marathon is now just a simple npx command.
The Problem Isn't Just Setup – It's Staying Current
Okay, so I built this thing to solve my own immediate pain points. But what I realized is that Yae Lint Config actually tackles some bigger, ongoing issues every engineer faces with modern linting in places like Next.js projects:
The Flat Config Wall: ESLint's new flat config (eslint.config.mjs) is awesome, no doubt. It's more predictable, clearer, and handles modules better. But setting it up from scratch, or migrating old configs, is a hassle. My tool generates a clean, commented eslint.config.mjs file, so you don't have to wrestle with the new syntax yourself.
Next.js Specifics: You're not just linting JavaScript anymore. With Next.js, you have specific rules for components, image optimization, Link components, and all sorts of framework-specific quirks. Yae Lint Config is pre-configured for this. It's not just a generic linter; it knows Next.js.
Dependencies, Dependencies, Dependencies: Ever set up a linter and then get smacked with a dozen "missing peer dependency" warnings? Yeah, me too. Yae Lint Config is smart. It figures out what plugins you need for the rules you picked and just installs them for you. It even detects if you're using npm, yarn, pnpm, or bun. No more manual npm install marathons for linting packages.
Interactive, Not Intrusive: I hate sifting through docs just to figure out what rules to enable. With this tool, you get an interactive CLI. It asks you what features you want, and boom, it builds the config. It's about getting you up and running quickly with solid defaults, letting you focus on the actual code.
The Features I Actually Use (And You Probably Will Too)
So, what exactly does yae-lint-config help you put in that eslint.config.mjs file? These are the features I found myself wanting in every project, and now they're just a few keystrokes away.
✅ Import Sorting: Look, messy imports are just annoying. This sorts them automatically, making your files cleaner and easier to scan. Saves tiny bits of brainpower, but those add up.
✅ Unused Variables Detection: If something isn't used, it shouldn't be there. This helps you keep your code tidy and reduces unnecessary bloat. It's like having a little clean-up crew.
✅ TypeScript Rules: If you're doing Next.js, you're probably doing TypeScript. This integrates the proper TypeScript linting rules, catching type-related errors before they become bigger problems.
✅ React Hooks Rules: React Hooks have their own rules of the road. This makes sure you're using them correctly, avoiding common pitfalls and keeping your React components robust.
✅ Accessibility Rules: Building accessible apps is just the right thing to do. This bakes in JSX accessibility linting, helping you spot things that might hinder users who rely on assistive technologies.
✅ Code Quality Rules: These are the general "good practices" rules. Things like preferring const, flagging console.log in production, and other common sense rules that keep your codebase healthy.
Quick Start: How I Get Linted Now
Seriously, this is it. This is my new workflow for linting on a fresh Next.js project.
npx yae-lint-config generateThe CLI pops up, you pick your features, and it does the rest. It installs the packages, sets up the eslint.config.mjs file with comments, and you're good to go.
Then, just run ESLint like you normally would
npx eslint .or
npm run lintIt's actually that simple. The time I used to spend wrestling with lint configs, I now spend, well, building things. Which is the whole point, right?
Who Is This For?
If you've read this far and nodded along with my frustrations, then Yae Lint Config is probably for you.
Next.js developers who just want linting to work without the headaches.
Teams trying to keep their code consistent without forcing everyone into manual setup hell.
Basically, anyone tired of linting being a constant friction point.
What's Next? (And What It's Not)
Look, Yae Lint Config started as my personal solution to my own specific headaches. Because of that, it might not have every single edge-case or every obscure rule that everyone expects. It's built around the plugins and configurations that I found myself consistently using and needing for modern Next.js development.
I'm continuously working on it, adding new features and improving the tool based on what I (and hopefully others!) find useful. However, I want to be clear: this is not a full, universal replacement for all your linting needs. Depending on your application's unique specifications or very specific team standards, you might still need to dive in and write some custom rules on top of what yae-lint-config provides.
Think of it this way: for most small to medium-scale Next.js projects, especially the ones I'm building, this tool will likely do the trick without you ever touching a custom rule. For larger, more complex applications with highly specialized requirements, yae-lint-config serves as an incredibly robust and efficient starting point. It gets you 90% of the way there, letting you focus your energy on that crucial last 10% of customization, rather than starting from absolute zero with a blank flat config file.
So, if you're building with Next.js, give yae-lint-config a shot. It's a small tool that solves a big problem, and it might just turn your linting "weak point" into a "strong point."
Checkout Yae Lint Config
Contribute on GitHub