Custom ESLint Rules

[00:00:00]
>> Steve Kinney: We'll talk about custom rules, but I just want to make the caveat now, which is, if you can avoid writing a custom rule, you should, right? Because one, why wouldn't you use something that existed? Two, right, something that exists has at least been battle tested, right? Because like a situation that I caused for myself three weeks ago was I had written a custom role to do something, and it wasn't all the, like I had like missed something in my thinking, and it was slow, and had a like a memory leak, right?

[00:00:35]
So like, it is a strategy to employ for a specific purpose, but you're like, it's always worth checking if a current rule exists, you know what I mean? And so like, yeah, can you solve it with an existing rule or plug-in, go do that. If it is something specific to your codebase, like again, we have a directory called legacy components, and we have a directory called new hotness components, right, and we'll look at a tool called, have you all heard of like Husky and lint-staged?

[00:01:09]
Alright, Husky and lint-staged are basically tools to say like, it's like, upon committing, run these scripts, and lint-staged will be only the ones that changed. So a strategy that I really like for doing migrations and refactors is like, you can set like the rule when you're running lint-staged and like, if that file has not been touched, it can use the old thing. And, you know, you gotta decide, everyone on the team has to sign up for this lifestyle.

[00:01:43]
If you touch the file, you gotta update the file. You know what I mean? And like it does get you to a world where slowly over time, like, you replace the old button component with the new button component, or you found a page that gets touched so infrequently that it probably doesn't matter. You know, like, my joke on performance is like, I don't care if you run a performance audit, and your worst page on your entire site is the terms of service page, right?

[00:02:13]
That's probably not the first one to refactor. Right, it's like, there's this tool Skylight and it had a metric called agony, and agony was like page load time multiplied by traffic. Right, and so if you had a slow page or slow code path that no one visited, that's not, like your worst code path that no one uses should not be the first thing you refactor. Something maybe further down the list of like getting the current user model is the thing that you refactor, right?

[00:02:46]
And so like, there are ways to like apply this for your unique thing, but like ideally, if it's unique to your codebase, knowing that you could write a custom rule is probably easier than being a big meanie in every pull request. Right. Because like, you're going to miss stuff, everyone's going to miss stuff, and then nobody wants to have those conversations. And if again, if it is enforcing like an architectural boundary, like I have softened up a lot on the like, I like parentheses around one argument arrow functions.

[00:03:25]
I don't care. Right, like Prettier will handle most of that stuff and honestly I've had to let go about that. But like, don't cross over the architectural boundary to grab a file that isn't exported by that thing because you think you need it, like that is going to cause tech debt for us forever. Probably a good idea. So, talking about this kind of like is the shape of an empty rule, and so, first, you know, you've got meta, which is like, just about the rule itself.

[00:04:00]
You know, if you've ever run ESLint --fix, whether or not it can be fixed, so on and so forth. But the important part is, most languages can be broken out into an abstract syntax tree, which is it goes to the language that makes a giant object of what it is. And you can kind of go into something like, if you've ever seen AST Explorer. I don't remember if it was, it was a .net. I was like, I'm not guessing the top level domain.

[00:04:41]
But you can kind of like do this with anything, you can say like, most things that we use, take the code that you write, you can break it out in, to effectively an object that is a representation of the code. This is how like JSX turns itself into JavaScript. TypeScript can compile it into JavaScript, like Svelte will turn it into JavaScript. So on and so forth, where you can take some code and it becomes, again, a giant JSON object that you can just kind of navigate and analyze, right?

[00:05:21]
And so now you can say like, hey, if this pattern exists, then I want to go ahead and like, either call a warning, count how many times we, how many places do we need to refactor, right? It's a great way to do either static analysis of your code or transform the code when we get to codemods later. It's a powerful idea that can like do a lot of fun things. And like you can like literally pop it in, you know, some code in here and kind of get a sense of the structure, right?

[00:05:47]
And the cool thing about AST Explorer is that also when you hover over the JSON object, it will kind of show you what you're looking at. So here's like a block statement, right, and I can expand that. And there's the return statement, and inside the return statement, there is like a binary expression, right, which is the a plus the b. And so you can begin to like, because you were going to regex it otherwise, weren't you?

[00:06:13]
You were going to regex. I know you were going to regex, and that was going to be a different set of sadness because like, we know we can't do that, but you can find the operator, you know, you can, whatever you're looking for in this case. So going back to the slide, right, it will kind of walk down the entire tree, and you're saying like, oh, we found an import declaration, right? And is forbidden to import is some function we wrote somewhere else, right?

[00:06:43]
And like, oh, it's one of the things you're not supposed to, like we're trying not to import, right? And then we can kind of like add it to the report of like, do not import from this thing and like show where it was. And you can have that as an error that you enforce in CI/CD or you can just start with warnings, or like the same approach will work outside of ESLint, where you can just at least count them, right, use case that I had a few years ago was the design team kind of just wanted to know how many colors we had.

[00:07:23]
You know what I mean? Like, exactly what was the, of all the colors that we thought we supported, how many, or like, how many buttons do we have? Right, and it's an interesting way to like generate those reports and then like, even if in CI/CD all it is is generating a report, you can hopefully watch it go down over time or up, depending on what direction you wanted it to go, right, and all of these things as well.

[00:07:52]
This is like a simplified version of AST Explorer, and you know, you can kind of like find the various things that you were looking for. Also I will say, you know, and I will show you some of these that I've written later if you really want to see them, but you don't want to see them because they are insane to look at. I used to write them by hand. Do you know who's really good at this? Claude's really good at this one, right, so like, my advice to you is if you're like, all the syntax that he's showing me makes me wanna cry, understand that there's a thing that you can do, and let your AI friend write it.

[00:08:31]
Like I have written these by hand and there's never, I mean, I like it because it's like a Sudoku puzzle, right? And I was a manager and like it didn't matter when this thing got done and I was doing it during meetings I didn't care about, but like, I like to let Claude do it more, and now I can generate code and I can do some of these checks. It's again, this is about the strategy rather than the like, and this is the exact code you would write to do the thing.