typescript-eslint with Josh Goldberg
===

[00:00:00] Hello, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. You can try it for free at logrocket. com. I'm Noel, and today we're welcoming back Josh Goldberg. Josh is an open source maintainer, speaker, author working on TypeScript ESLint.

He's here to talk to us about best practices and formatting linting in the JavaScript TypeScript space. And we'll talk about what TypeScript ESLint does and how it fits in and what's new on that front. Welcome back, Josh.

Thank you so much. It's great to be back. How are you?

Good, good. I'm excited to chat. Yeah, , I know this is a, good topic. I feel like devs always like talking about tooling that makes their life easier. So this is always a good place to dig in. But let's kind of, let's contextualize this a bit. This might be the same spiel you gave us last time you were on, but can you tell us what you're working on what you have been since we last talked and maybe set this up for us a little bit, where [00:01:00] TypeScript ESLint fits into the linting TypeScript ecosystem today.

Very high level. There are three common forms of tooling that runs in your code before your code runs, aka static analysis. There's formatting, which just reformats your code. It doesn't change behavior. There's linting, which lets you know if something seems like it'll probably be wrong and can oftentimes suggest how to improve it.

And then there's type checking. Type checking. Which generates a full on understanding of all your code, if possible, and lets you know when things are definitely wrong. TypeScript ESLint is a tooling that lets the standard JavaScript linter, ESLint, understand and use APIs from TypeScript, the standard JavaScript type checker.

And that's what I work on.

Nice. Nice. Yeah, so let's, yeah let's dig in a little bit immediately. I'm curious on, on the boundaries. I don't feel like we talked about this too much last time. So like, you know, Like you said, TypeScript is interesting, because , we end up with these three different things happening.

[00:02:00] TypeScript ESLint reach, or what is it analyzing, maybe, is the cleanest way to ask that. Is it purely doing syntactic analysis of type declarations and things like that, or is there anything beyond that, that it's either doing or enabling?

I'd say there are two types of rules. And just to be clear, so the ESLint team doesn't get mad at me, this is true for ESLint and all the plugins and parsers that work on top of or with ESLint, including us and TypeScript ESLint. A lint rule will traditionally just look at the syntax of your code.

If you have a variable, whether you, say, use var, let, or const uh, what the variable name is, if it has an initial value, and so on and so forth. TypeScript ESLint. also provides tooling to allow lint rules to pull in type information from TypeScript. So in addition to understanding, let's say, whether the variable has an initial value or not, it can also check what type that initial value is, even if it's referencing something imported from a module that comes from node modules etc.

[00:03:00] Which means in addition to being able to provide nice built in ESLint complaints on TypeScript code, let's say you didn't use this variable. Or this variable was a let, but could have been a const for your code style. We can also tell you, based on the type of the variable, or the type of some value in your code, you might have, say, used the wrong loop iterator style, or created a promise without adequately handling its rejections.

So we don't significantly change what a linter is, we just make it much more powerful and able to tap into a lot of cool stuff it wouldn't have been able to know all the time previously.

Yeah, it's, again it's an interesting space because I feel until one spends some time thinking about this, it may not be super evident why the linting layer needs to care about types because oh that's what the type checker is for. But then I think upon reflection, it's oh actually, I have rules.

That before the linter was handling, but now I have this type of information. So I want to be able to do more with it, but it's not really like strictly a typing [00:04:00] thing. It's I just want to enforce certain code styles and rules that, are emergent from the type system itself. Is there what's the cleanest way to ask this?

Is there any. Was there pushback initially when the, TypeScript ESLint project was in its early days or was there debate around what is the correct way to have this all function?

Oh yeah, there was so much debate. I was not one of the initial creators of TypeScript ESLint. Um, I only joined a couple of years ago as a maintainer. I used to work on TSLint. I also did not create that thing. I just float around the ecosystem, contributing to projects that are already created by other people.

So back in the day, we didn't use ESLint on TypeScript code. We used TSLint, which was like ESLint, but worked natively on TypeScript. Advantage there, cleaner implementation. We just support TypeScript. You're guaranteed TypeScripts. APIs work downside is you then have to re implement everything that ESLint did because the way TypeScript represents code is different from how [00:05:00] other standard JavaScript toolings such as ESLint and Babel.

So that was a whole pain in the butt. That's why we now instead use ESLint as the base. And then ESLint can be configured to use different parsers. For codes such as TypeScript ESLint's parser. So that on its own is just a whole can of worms and there's no great answer here. And eventually they're thinking of rewriting ESLint altogether to make a lot of this more streamlines.

But for now it's a whole thing. . 

yeah, so kind of, I guess , in that same vein, just so we're not like leaving that dangling too much, is this is this pretty settled for the most part?

Is there new dev setting up a project. Should, would you advise most people like just use TypeScript ESLint? Don't think about it too much. Is there any other, anything else that even should be considered at this point? Or is it a settled debate?

It's pretty much a settled debate for now in that there's really no industry standard way to lint TypeScript code other than ESLint with TypeScript ESLint. That being said, there are a [00:06:00] few long term bets plays that might pay off with changes to that. For starters, ESLint will eventually be right itself.

They've been going through RFCs and discussions and such, and I'm really excited about that. It's going to be quite a few years but still. There are also other projects that aim to make things a lot simpler. For context, one of the big downsides of TypeScript ESLint is that because we're an extension on top of ESLint, we're just a plug and play.

Plug into ESLint, there is some configuration, some shenanigans. So people have made tools like Rust or I think another one, I'm sorry, Rome or OSC. There are like a few efforts to do it all seamlessly. The problem with a lot of those tools is that although they might be much faster for, let's say being written in Rust, none of them have successfully integrated with the TypeScript APIs.

So they can't actually use type checked linting, which is by far and away the biggest value prop that I think TypeScript ESLint adds to the core ESLint experience, other than just letting you lint TypeScript syntax at all.[00:07:00] 

Is that just if I can, if we can open up the hood a little bit, is that what most of the code in the TypeScript? ESLint code base is actually doing. Is it like the, what's necessary to get that typing information and service it to ESLint? Or like what is, what are most of those lines actually concerned with?

Most of those lines are comments with big to dos saying delete this and the next page, just kidding. We just had a major version. So there are a lot fewer of those lines than there

Okay, good. Yeah,

I don't know the exact line counting, but in spirit the mind share for me is split roughly threefold.

One is in the parsing logic, which takes in a TypeScript, AST abstract syntax tree representation of your code and converts it to the equivalent ES tree ECMAScript tree, the format ESLint uses. So even if you're not using type linting, that's what we do to allow ESLint to read in parsed TypeScript syntax.

The second group is what you just described. We have a whole bunch of code around type checking. [00:08:00] And actually we're working on some really exciting plays, long term bets with the TypeScript team to hopefully make this a lot simpler and closer to what editors feel like. So it'll be easier configuration and faster. And then the third is we have this huge list of rules, some of which are just extensions or forks of core ESLint rules that make them work better with TypeScript, some of which are our own rules that are do things you can really only do with TypeScript, let's say checking TypeScript specific syntax or doing things that you need type information for.

gotcha. That's a good segue then. Okay. So let's talk like specific rules and stuff a little bit. Are. Are there good default rule sets? People should be pulling off the shelf to use or what, how do you recommend people figure out what what rules to enforce?

This might be my favorite question I've been asked ever. Yes.

What a compliment. Yeah.

Yay! One of the reasons why we just released a new major version is because we wanted to rework the recommended rulesets. For context, most [00:09:00] ESLint plugins expose some kind of recommended preset that you can extend from in your config.

This has been the case for many years. A lot of developers might remember ESLint, Config, Airbnb, which had just a recommended plugin that people pulled in, got a lot of annoyance over stylistic.

Yeah. Yeah. Yeah. 

Yeah. We don't, they've improved over time. What we've learned is that you really shouldn't be including stylistic recommendations that don't make sense for everyone in your recommended presets.

That's how you annoy people, make them hate the linter, and train them to ignore lint warnings. instead, in v6, our most recent major, we changed our configs in a couple ways. One is now we have three basic configs that you might want to extend from. Recommended, strict, and stylistic. Strict is a superset of recommended.

It's just the recommended rules, plus some ones that are a little harder to align with, but are really nice, we do recommend them.

Then there's a separate new stylistic config, which is all of our stylistic recommendations. Don't yell at us, just this is how we like to do things and think [00:10:00] most types of projects generally do.

What is the, give us an example. Or maybe here's the, here's an interesting one. What is like the most tricky or rule you found the most tricky? Does this belong in stylistic or is this an actual functionality rule?

We have been having so many conversations around rules that prevent you from accidentally stringifying things in incorrect ways. We have two rules around, you're nodding because this comes up a lot, right? We have two rules right now. We might end up with one or five in the longterm, no base to string and restrict.

What is it? Something about the template literals. So the idea is in JavaScript, you can stringify anything. The default to string. Is just object with the square brackets around it. So if you console dot log, let's say a template literal and you put in an object in there that doesn't have its own two string, it'll just come out as object, which 95% of the time is a bug, if not 99.

9. So we have lint rules against this. It's restrict [00:11:00] template expressions, which says things that are put in a template literal should have a reasonable two string. Don't put in like a number or an array or something, but then people are like I want it to log a number or, put in an array because it's natural dot join.

So then we had to add a bunch of options to those rules to say, allow number, allow boolean, allow nullish, whatever. But at that point, the rules are doing nothing because anything you put in there other than just an object is going to be okay.

So. We don't know what the right thing is yet. We're still talking about it.

We keep going back and forth. One of our maintainers, Brad, has very informed, hard opinions on this, and I keep waffling on whether and which of those I align with.

Yeah. I think that could be helpful though, right? Like you need somebody with strong opinions and another person like vetting those. And I feel like you end up with this happy medium , does it take a lot of energy? Do you feel like it's draining, like figuring out these highly, I don't know, prescriptive endeavors always just feel like you have this weight upon your shoulders. Is it, do you enjoy it or do you find it, a little bit tiring?

[00:12:00] Definitely both. I enjoy it. A, I think it's intellectually stimulating. Trying to figure out, ideally using as much user research and such as possible. What do people actually want and need? Those two are very different oftentimes, want versus need. But also, I feel a lot of weight. Because we are the standard linter for TypeScript code.

If we do something obnoxious, we're going to turn away untold dozens, hundreds, thousands of developers. Who may or may not ever inform us that now they hate us and we'll never use us again.

And then also we spend so much time talking about these little nuances, but we also have a lot of, really important other stuff to do like performance and new rules and just updating to the latest version of TypeScript.

So it's a hard balance to draw there.

Yeah. Yeah. I'm sure. Is there in, in coming up with these rules sets and you said you're like trying to pull in as much, sample data as possible. Are you guys using tooling to help with that? Or is it more of a manual anecdotal thing or what's the process look like?

It's a lot more manual anecdotal than I want it to [00:13:00] be. We. We are a monorepo on TypeScript, a couple thousand TypeScript files. So we are a good source of user advocacy, we are a very specific type of repo. Every repo, every group is different. We try to be active online. We I'm very active on Twitter.

The other maintainers are off and on as well. Everyone is off and on these days. We have a discord that opened a, whatever, a few months ago that has gotten. a good amount of activity recently. We also whenever we make a new version now, our standard will be to make a discussion on GitHub discussions with a big description, a giant table of all the changes we want to make.

And we try to solicit feedback. Lastly we've gotten in the habit now of trying new changes that are big out on community repos. So this is actually an open invitation. If anyone has a repo with a more than a few dozen files, they want to be tried out on, let us know. We did it for V6 with the rule changes on repos from Astro to TypeScript, and it was really useful.

Nice. Nice. That's awesome. Yeah. Yeah. Is there, are there any kind of, is there anything [00:14:00] in particular right now that is, is more of a challenge, like even on the developmental side on the, parsing side, taking those trees and coming up with recommendations? Is there anything, challenging or new?

That you guys are working on right now that devs might be excited about.

Yeah. Simplification of configuration. This is good for two reasons. The most direct one is no one likes configuring tooling, let alone a linter. First making good recommended presets, people can actually extend from without having to say, turn off a bunch of stylistic rules. That's nice.

But also the way that type checking works is it's an opt in. We won't enable type checking just because you include a rule that asks for it, because that could be very surprising and obnoxious. All of a sudden your whatever 3000 line code base takes much longer to type check and lint just because of some random rule.

So the ability for people to specify how that type information is generated is sometimes non trivial. If you've got a monorepo with a bunch of different TS configs [00:15:00] all extending from various other bases and tsconfig. es lints. A few months ago, we added in a new option, parseroptions. project. true.

Instead of manually specifying the paths to your TS configuration files, you can just say true so that each file will look up the closest one and it's nicely cached behind the scenes. That's helped some people it's just easier to use, but what I'm really excited about is we're trying out an experimental option called experimental use project service, which uses a different API from the TypeScript side to create TypeScript projects for each file.

And it's actually the API used by editors. So even if you don't have a TS config that directly says, yes, I will allow this particular file to be type checked, say your eslint. js file, we'll still be able to use an approximation of what the type information should be.

nice. So that's like the same logic, whatever, like VS code, the VS code when turnstuffs using currently.

Yeah, which makes sense. If you were using, let's say an editor like VS code and [00:16:00] yellow or red squigglies from ESLint, and then you run ESLint on the command line, it would be very annoying for those to be different.

We're really excited about that one.

Yeah. Yeah. I haven't spent too much time thinking about that, but it makes sense that there would need to be some, yeah, there's some logic there happening. So it's like not overburdening the system when you open these large projects, but like you're getting stuff in real time.

And you do, you see it churning and doing its thing, but I haven't like really, stepped back and thought about what's happening. Yeah, is that tricky or are you able to plug into these kind of plug into this logic that the, editors have been using for a while?

It's tricky, but not a large amount of code. I want to shout out Jake Bailey from the TypeScript side. Who's been really kind to us and helping us through a lot of this.

Right now the project option use experimentally use project service. It's not even documented on this site. I have an open pull request that'll be merged eventually.

We intentionally are keeping it very on the DL as we're flighting it out. We've seen it change performance on subsets of our repo, anything from 11% worse performance in some [00:17:00] areas to 70% better. 

Gotcha. 

we're very scared of this thing. I am personally terrified of it.

Yeah.

yeah, it'll, I think it'll long term both simplify our code base a lot because we'll be able to do a lot easier manipulations with it.

It is a really nice API and it'll simplify other people's code bases and oftentimes improve type check and performance quite a bit.

Nice. Yeah. I'm sure that's, appreciated by everyone. It's nice when you open files and, everything corresponds and you run the thing on the command line. Like you said, getting the same output,

super super nice. Scary when it doesn't happen. It's Oh something's broken.

I've done something wrong. I've got to go figure it out. Yeah. Let's talk about like other kind of other things more in user land. Like, Are there any other new, I don't know, rules or capabilities that TypeScript ESLint is enabled recently or could with new rules that devs might be interested in?

I don't have a great new thing to show off other than the parser options stuff.

And the reworked configs, I will say in my experience, most people don't think deeply about their [00:18:00] linter. But we now have a really, I think, fleshed out documentation site, really, I think, thought out preset configs.

So I'd say take a look at your linter config, see if you're on TypeScript, PSLint 6, and try starting from scratch, just enabling the extended recommended rules from our plugins and any you use enable type checking. See what happens each of our recommended config types, recommended strict and stylistic has an option, a version of it.

That's that type checked. So say strict type checked, which also is a superset of the base one. And we'll pull in type checking rules. And those I've seen a lot of people be very surprised and pleased at the types of bugs you can catch with the tech check rules.

Yeah. Yeah. It's I think, , devs. Like they see those stories online or it's like, I enabled this lint rule, especially like with type checking. And I found some bug that was like waiting to get me and I caught it before. Or maybe it like has been happening, but it's been silently failing for people.

Or there's something we couldn't figure out for the longest time. And then like some [00:19:00] automated tool, some linting tool, solved it for us when enabled. That's always such a, 

Yeah. 

positive story.

Definitely, we've been working with some of the popular frameworks out there that have their own project builders to, to get our recommended rule sets in there. I believe remix create T3 app are in some way already on boarded and I'm working with the next JS team to all these people have been very kind.

I freaking love open source in part because I get to work with really nice people on the internet. I'm, I filed an issue on Astro recently. If anyone has a thing that creates projects that use ESLint. Let us know. We'd love to work with you on getting our recommendations up in there.

Yeah nice. That's a, that's an awesome callout. Yeah, so like, we've covered a lot here, and I think it is circling back slightly like you said, there's not a ton of shiny new rules, but that's probably a testament to like, we're hitting maturity in these spaces.

There's just not a lot of changes even happening anymore that are that drastic where, there is new... Or people are calling for new rules at the linting layer, but I [00:20:00] could see, I'm trying to think. Like stylistically, I could see there, those things shifting more over time.

How do you guys have a good, I guess maybe we should break this down a little bit. How do you tell developers to like, think differently about like what the difference is between formatting and styling?

Oh, what a great topic. There are four words here that a lot of people in some different way, use interchangeably that we're trying to be more and more over time, different time, logic, style, formatting. And, Oh God, what's the fourth one? Something else. There are three words.

Yeah. Yeah.

three words that people use interchangeably logic style formatting.

Some people interchange logic and style. Some people interchange style form. Formatting is anything that seems stylistic, but does not actually change the logic or most of the time, even the backing representation, the AST of your code. Things like semicolons, whitespace, your indentation level.

That might be important to some people. For example, [00:21:00] tabs have a whole nicety around accessibility. Spaces are less nicety, but they don't actually change the logic of your code. So that's formatting, doesn't, not only does it not change your code logic, it, for the most part, doesn't even change the way the code is represented programmatically, for the most part.

Stylistic rules might not change the logic of your code, but they do change the way the code is represented, like naming a variable differently, or using an arrow function instead of a function expression. That is different from formatting, but there is a blurry line between them. I just had a blog post on this.

Every time I write on this subject, there's a little bit of rage on the internet, 

Yeah. Yeah. A little hand waving and people get mad about it. Yeah.

Oh, yeah. What better to get mad about than style and formatting instead of, you know, things that are truly impactful. There are some things that blur the line. For example, whether you always write curly brackets after your if statements in for loops.

That's arguably style versus formatting. Formatters won't touch it because It changes the AST, [00:22:00] 

lint rules often won't touch it because that's nitpicky. That's not what a linter is really for.

That's the one blurry line. Then there's also a blurry line between style and logic of , there is an actual difference between using, let's say an arrow Lambda versus like a function expression. Sometimes it doesn't matter. Once in a while, it does. For the most time, we care about logical stuff only when it actually significantly changes behavior to the point of likely causing a bug or something unexpected, whereas stylistic rules are ones that are just for readability or consistency, not a hard and fast rule.

I'll eventually write a slightly incendiary blog post on this too, but that's generally where I start from.

No, yeah, I think that's a good good kind of framework to discuss this. So then, yeah, circling back to my previous question, it feels to me that kind of, I don't know the logic feels like it'd be more, or changing less than style, in the ecosystem, and then that seems like it'd be probably formatting as opinions change over time.

Is there, Do you think that is true? [00:23:00] And if so, like, how do you recommend devs ensure that they're pulling in changes as these norms kind of change throughout the. Programming ethos over time.

It's a great question. I truly can't say whether one or the other is changing more or less. Maybe logic is in my perspective because. The backing frameworks that people used to write code at the very least in my observed areas of front end and full stack are changing a lot. We got the new versions of Astro and Next and Remix and whatnot with React server components and equivalents.

So a lot of small things that previously were considered bugs or not considered bugs are now switching. For example, we have a recommended rule in type GPS link called, I think it's require or wait, where if a function is async, it should have an await keyword in it. Otherwise, an async function that never awaits, it's just slightly worse than a regular

function in terms of performance. 

But, I forget [00:24:00] which part of React server components and or Next. js, I forget which library dictated this, said that some type of methods, props should be async, even if they don't have an await. They just have to return a promise. Those two things are now in conflict. If you have a, I think it's a server action, let's say,

that's, It's not needing to be async. So as frameworks change, those assumptions around them change, but also as languages and best practices evolve over time, they change and TypeScript, we keep going back and forth, whether you use, let's say type or interface to the two common ways to declare an object shape, but honestly, none of that really matters in the moment.

Just use the recommended presets and then make your own informed judgment on which of those rules to turn off or turn on based on your project's needs.

Yeah. Yeah. So if I guess real quick, yeah, like I've run into this. Yeah. Like I feel like these things are things that do come up. Like we, one always assumes it's oh, how often are you actually going to have something where this rule will break in all instances except for in some framework where, you have this strict [00:25:00] typing, it's it seems like it would never happen.

But then I feel like it does happen all the time. It's like, oh, dang it. Like, I've got, you know, like, like, there's some weird like, I just hit this, a very similar problem with like, I had this whole structure. I was using a library and I needed to be using an async function, but then I didn't need to await anything in it.

So I was like, how do I like abstract this and put a wrapper? Like maybe there's some teeny little performance impact. Do I just eh, it's fine. Like I'll just ignore it and it's no big deal. So anyway, I think, yeah, that they, that time does end up being spent there inevitably. Um, But then, yeah, like back to my previous question if a dev or a team is using these like preset rules, do you.

This is probably like more of a question about just linters at large as there are changes in the ecosystem or just in how devs are thinking about these things. Is it, would you anticipate that teams, when they like do version bumps and stuff that the rules would be switching out from under them in a way that they would need to make, code changes to bring themselves up to whatever the, [00:26:00] preset that they're pulling in is telling them to do.

Great question. You never need to make runtime or even stylistic code changes when you have a new form of static analysis for any of the three types. Type checker, linter, formatter. You can always ignore new rules or add a equivalent of an slint disabled Next line or tss, expect error. Which say shut up particular tool about the next line.

Don't worry about it. I highly recommend that you do not change runtime behavior in the pull request that updates the version of a static analysis tool. You file a to do it next. Because I have tried this and time again, I will fix something that the type checker or linter is 100% sure is a bug in code and couldn't possibly be correct.

And then I cause a bug. And then not only is this giant PR that has to be reverted or surgically fixed. Now people are like, oh, updating TypeScript causes bugs. Let's not update TypeScript. What a terrible lesson to [00:27:00] take

Yep. Yeah. Yeah. I'm sure there's a lot of devs like at home nodding along. Like I am here. Yes, we've all done. We've all done this. Yeah. Oh, I'm just updating the linter, the type checker or whatever. And then, oh, I like. Yeah. Do all these things and I'm like, you're going through and you're like making 300 changes and most of them are the exact same thing over and over.

And then even like there, like you said, there are bugs that you are introducing systematically, but I think you also want becomes much more prone to just like user error. And like the code reviewers job is much more difficult. So yeah, I think that's

Empathy for the code reviewer who wants to review 300 instances of changing from one declaration form for an array type versus the other. Silly. So the general recommendation I have is to whenever you need to update to a new version. Especially if it's a big new one, then that changes things a lot, such as our V6 disable everything that would cause a lot of work on your end, or even just a lot of changes, even if they're automatically applied with link dash fix, and then put a big to do [00:28:00] link to some ticket.

That describes exactly what I'm about to say. We are not sure whether we want these investigate, whether we want to enable these rules and then some fun emoji, like a sparkle emoji, because that's always good.

Yeah. \ keep the eyes on it. Yeah. Is there anything , like tooling you can recommend to make that process easier? Or do you think it's just a,, process problem. And you got to go through these steps to make sure that there's no bugs introduced to you.

I'm currently Googling because I know there are tools out there that will run ESLint incrementally. And for the life of me, I can't remember their names. Someone will yell at me on Twitter or whatever the buffoon is calling it now. And that'll be a whole thing. But yeah don't be afraid to turn off rules in your configs, as long as you put a nice big to do next to them.

And don't be afraid to ESLint disable next line with a to do and an explanation of why the lint rule is disabled in this one particular case. It's much better to have a rule [00:29:00] turned on and then ignored in a few specific cases, if that rule is useful, then to never turn the rule on and miss out on the potential usefulness of the rule.

All right. I'll push a little bit here. At what point do you like, say you have a rule enabled, you like the idea of it, but you find that in whatever a given code base that you're basically having to disable it? Almost all the time. Is there a point where you're just like this rule probably doesn't apply anymore or, isn't, doesn't have any utility here because I'm disabling it more often than not,

Great question. Yeah. I'd say figure out why you're disabling it. There are three common reasons I've seen why people disable a rule frequently. One is that the rule just does not make sense for you. In that case, disable the rule. If you're on a project that very frequently, let's say, declares async functions without a waiting, then don't turn on require await.

That's fine. The second is that developers are not familiar with it and, or just don't have time to deal with it. Oftentimes you'll be on a team where not everyone is super juiced about [00:30:00] ES lint and static analysis and dev tooling in general, or some subset of that. And they just haven't gotten around to it.

They say, okay, if I copy and paste this other function including whatever comments are inside. Nothing breaks, the build passes and I can merge, which then brings up the question of why did no one code review that away? What if two people don't care? So see if there's a person skills, a structural issue with the team that's causing all these things to be ESLint disabled next line.

Maybe this is actually a case of the first thing where the rule doesn't make sense, but the people just weren't talking to the web platform team or people who do web platformy stuff. In which case you've got a communication gap that you should resolve there.

Yeah. Yeah, totally.. I don't know. It feels like most teams are aware of this and everyone like likes having good health, and it's one of those. It's like always done until, whatever, the sky is falling, something's on fire, and you're like trying to get something out quick, and then it doesn't come back and get cleaned up, and then you're like having this debate three months later.

But yeah, I think it's one of those things, like it, the dividends pay off, and I think people have a pretty good grasp on that, it's just it's handy to be constantly reminded like [00:31:00] we are doing this for a reason, like we're making our lives easier.

Yeah. Yeah, definitely.

And I think I found it actually, ha, it's from someone I really like in open source, Ian Van Schooten ESLint Nibble.

So good. What a name. How did you forget that? It's such a good name.

I don't know. I'll have to apologize to Ian personally. I'm forgetting such a well thought out. It's that's a, that's one of the best names I've ever seen for a package.

Yeah, exactly. It describes what it does. Say it's perfect. Very good. Cool. Yeah. Is there any, anything else in, in B6 that is worth talking about or covering might be of interest to people.

We could go into a whole deep dive about how we dropped support for deprecated end of life versions of node. And that broke a lot of people who are running on old versions of node. But I don't think we have three hours remaining in the podcast 

Give me the short version though. Like what? I don't know. How did you cope with that? What's the, what was the conclusion?

So right now TypeScript allows. For projects to specify which module resolution algorithm to use. In other words, if you say [00:32:00] import something from somewhere, what is that somewhere? How do we determine based on your file system? What that somewhere is most commonly like a relative file or a package in your node modules, the ecosystem does not have one way to do that.

There are bundlers like webpack. There are native browser and node imports. Now there's a. A whole bunch of stuff out there. So the TypeScript compiler option, modular resolution allows you to specify whether you're using node 10, node 16, node next, bundler, a few others. The default thing that a lot of people have gone with modular resolution node is actually an alias for modular resolution node 10, which as those who have been following node know has been end of life for quite a few years.

In v6, we dropped support for importing from TypeScript ESLint packages. In module resolution node, you have to use node next or node 16 or bundler. That being said, two notes, one this is in our blog. We have two big blog posts announcing the V6 beta and announcing V6, and we very explicitly [00:33:00] called this out.

So whenever you update to a new major, please read the release notes. There, there's a reason why they went with a major. I will also note this does not impact the vast majority of users. You don't import directly from us, unless you are writing like custom ESLint rules or custom ESLint typing or tooling.

So the occasional package has been confused by this because they updated to v6 and now the modules can't be found. And the TypeScript error message in this case is just the module can't be found. Such as life, this major modular resolution to something that is not end of life, ideally like node 16 or node next or bundler.

Yeah. Yeah. And it feels like those things should be probably being addressed in tandem with

Yeah,

trying to upgrade your linting tool chain, but yeah, that's a different discussion. . Yeah. I guess. Is there, Is there anything else you want to, I don't know, just call out things on the horizon, even in the greater linting formatting space at all that you're excited about on the horizon.

Yeah. For starters, I will again repeat people, please try out TypeScript BSN V6 and give us feedback. We have a whole blog [00:34:00] post describing the changes and the new rule sets. Really excited. I think they're very useful. If you are an author of a framework equivalent to create something app let us know.

We'd love to work with you. Long term we're going to try out this project service thing that should hopefully significantly improve configuration and performance. I'd also say I'm personally working on a project called template TypeScript node package. I'm just collecting all the good stuff that I've seen packages do everything from linting and formatting to automated releases to automations around pull request reviews.

I might eventually rename it to create TypeScript app or create TypeScript node app. So if you have any interest in repository tooling, whether you want to learn from my stuff or suggest, Hey Josh, you should do this, let me know. I'd love to get as much input on that thing as possible.

Nice. Cool. We'll get as many links as we can in the show notes to like everything we've covered here. And, yeah, I guess with that, thank you so much for coming on and chatting with me, Josh. It's been a pleasure.

Yeah, this was really fun. Thanks for having me on again.