React, TypeScript, and ESLint with Josh Goldberg
===

Noel: [00:00:00] Hello and welcome to Pod Rocket, a Web development podcast brought to you by Log Rocket. Log Rocket helps software teams improve user experience with session replay, error tracking, and product analytics. You can try it free@logrocket.com. I'm Noel, and today we're welcoming . Josh Goldberg you've, Josh is an open source maintainer speaker an author working on es sl covering es SL stuff. He's here to talk to us about his latest speaking engagement setting up slint and type script for React.

Welcome to the show, Josh.

Josh: Thank you very much. I should note I don't work on Esly itself, that is a separate team from me, nor do I work on Typescripts. I work on the tooling that lets you run esly and prettier and similar tools on TypeScript.

Noel: Yeah. Covers, covers the general lin and tools that make your code better and easier to read and maintain space. It's all good. But yeah.. Give us a little bit more about your background and , what you work on specifically.

Josh: sure. First of all, thanks for having me slash back. Very excited to be here. Always fun. I. [00:01:00] started off as a more common software developer in that I worked on applications, a lot of front end stuff. I actually learned c plus more in college and then fell in love with JavaScript and the web.

So I worked at Microsoft in office before that Dynamics, which is their business stuff. Then I switched over to Code Academy because I really like Rich, dynamic Computer E. Applications and really wanted to work in EdTech. But each time I moved jobs or roles, I gravitated towards developer tooling, growing more to the point where I just really wanted to work in open source, shared stuff.

Things that help people write code faster, better, with fewer bugs. So that's where I am now. I work on stuff that I think is really useful for as many developers as possible in the TypeScript space. Sometimes I contribute to TypeScript ES slant or other tools. Most of the time I work on TypeScript ES sl.

Noel: Nice. Yeah. Yeah. I wanna get to type script slump, but I feel like we should go on a little bit more of a journey to get there, to contextualize that a bit. So originally , we have that you titled your talk Don't fear the [00:02:00] Linter. Why do you think devs do Fear the Linter?

Josh: , I honestly wish I had gone with that as the title. I had this epiphany in the shower in, oh, what a good title.

Noel: Where you listening to like Blue Oyster Colt and I was like, yeah, this is it. Yeah.

Josh: yeah. I've been going on like a binge of old, like SNL sketches. Not that's the most important

Noel: More cowbell. Yeah. Yeah. Yeah.

Josh: Yeah.

Noel: Nice.

Josh: Yeah, I think. For starters, people are scared of anything that's telling them they're wrong.

And a little red or yellow squiggly line in your editor is a scary thing to a lot of people, especially newer folks, to the industry folks who don't have years of experience kind of building up that resilience in them. If you're talking to someone who's just started coding, they don't really understand how, let's say React works on the inside and they're trying to right react, and then they get a squiggly saying, you did this core React thing wrong.

That's not a pleasant experience Out of the box. Now the right attitude for many people is to look at it as a learning opportunity and to explore. And [00:03:00] not everyone does that unfortunately. I'll also say that Es Linz and other Lins historically haven't always done a good job of phrasing the suggestions.

They will say things like, you're doing this wrong, and then they won't explain what the better way is. They won't provide a fixer links to docs. And I think we've gotten a lot better that at that as a community, as an industry over the last, say five, 10 years.

Noel: Yeah, I think so as well. , I feel anymore when I'm spinning up a new project and it ends up with that when I don't have a linter right away. It's like I'm trying something totally new and I've running some. Higher number version, more recent version of like node or type script or something.

And like I try to get the lin going and something fails and I'm just like, eh, I've got other stuff to worry about right now. Do you think we're getting better on that front or do you think there's a lot of projects that still kick off and it's just kinda like, oh, winter's another thing on a long checklist of items and people are like, trying to get V1 out the door and just whatever.

I don't need that right now.

Josh: Oh yeah those are both very pressing concerns, right? Yes. Even if the linter does a perfect job of coaching the questions or complaints it's making [00:04:00] in very nice, good ways. At show docs, sometimes you just don't have the time to learn these things. So I think one really key innovation ish in the space has been just not enabling rules that are obtuse or overly opinionated by default.

So that instead of being just another checklist, annoying thing, the linter is actually providing value out the box and helping you write your code faster, better, with fewer bugs, which is the goal, right?

Noel: Yeah, for sure. Yeah. That's a good, that's a good segue. Can you talk a little bit about formatters like how those relate to linters and help us get code out quicker?

Josh: Yeah, so this is still an open, contentious area in the industry. Not everyone agrees with me. In fact, not everyone who is notable and important and very well-respected and learned agrees with me on this one. But I strongly believe that a formatter and a linter are two separate tools that should be used separately and differently.

A formatter, in my belief, is a tool that just formats code. The big draw of it, the big marketing push that I think is most effective is telling people that it does the [00:05:00] formatting for you. So you don't have to manually press the tab or space or whatever keys all over the place. That's great. That saves you time, helps you just write code.

And also an interesting behavior I've seen is that a lot of people will use the format on save option in editors to know whether they've gotten their syntax right, so that if the file doesn't reformat itself when you hit save, oh no, you know you're missing a squiggly or

Noel: Yeah. Control like you mash that control S button and see what happens. Yeah. Yeah.

Josh: Oh yeah. And that, there's also the philosophical argument that a formatter establishes a very opinionated, often formatting style for your project. So you don't have to reconfigure your brain the way that you think about things. File to file. I think that's true and valid and good, but not as effective as a convincing people to use it piece than the other parts, which is unfortunate cuz I think it's really important.

Noel: Yeah, is anything driving your kind of, I don't know, stronger opinion that they should be kept separate? Other than that, just conceptually they're doing different things. Cause it does feel like there's a lot of, like places where the linter , would give me some [00:06:00] air here, but the formatter could fix this automatically.

So like those should or shouldn't be like squiggly line underlines cuz they're gonna auto-correct anyway. How do you think. Ideally if king for a day, like how would those how would that interplay work and what would the dev experience look like?

Josh: Yeah, that, that's a really good question and a hard one to answer from a structural perspective, a linter. Is most often implemented in today's world as a tool that runs a set of individual discreet rules. Each of those rules flags for one code smell or something in particular, and will flag or report on any violation.

That's what causes the little squiggly, and each of those reports may contain some auto fixes or suggestions for how to fix your code Now. In theory, you could use a linter as a formatter, and there are some notable projects that do that, and that somewhat works. It's fine. A lot of people are satisfied with this, but the problem is twofold.

One, that's not what a linter oftentimes is built for. A linter [00:07:00] allows for running individual rules, which then. Causes a bunch of reruns, which makes it much slower because rules will fix for specific things and you end up running the winter over and over again in fixed mode to fix for formatting.

So it's just, it's worse at it. It is much worse at formatting than a formatter

Noel: Sure.

Josh: second just. Theologically, how do you set up a linter for formatting? There's so many different concerns, like tabs for spaces in dense level, putting things on the same line versus next line, configuring the maximum length of a line.

You. Can use a linter for that. But there are these edge cases that the linter will never be very good at fixing. And in TypeScript P SL land, we've completely given up on accounting for these edge cases in many of our formatting rules because it's just this never ending anger from people of saying, you know, and this 300 line file, this little edge case comes up and we just don't have the budget.

It's not worth our time to investigate these things. And if someone wants to go in and fix them for us, that would be great. But no one has stepped up [00:08:00] yet.

Noel: Do you think that. , it'll eventually be the norm where when devs go and are starting a new project or adding formatting and lin to their project, that they're pulling some kind of configuration, off the shelf or out of a package or somewhere, something where it's like defined for them and it's okay this is the domain that's handled by the formatter.

This is what's handled by the linter. They are all configured to do their things. Or do you think that'll always be like the devs will bring their own and make it work however they need to per project?

Josh: I think the norm that we're moving towards is both of those where we'll have preset up templates that do things for us and we're already seeing. Languages like Go and Dino or rather languages and frameworks Go slash Dino set that up for people or projects like XO that set it up for you. No one really wants to have to configure these things, but then you do need to be able to configure them, like especially with Slint, which is despite being a decade old, still getting more and more powerful and more and more used each year.

We want people to be spending time on things that are valuable for them. So types PS land, it's more that we're trying to [00:09:00] set up TypeScript configuration stuff for you, and then writing powerful rules so if you wanna configure them, can tailor them to your use case.

Noel: Yeah. I guess maybe , this might be kind of a tricky question to answer, but do you know. How much customization are most devs and teams doing to the default rule sets for Iceland? Are they, are there people like spinning up a lot of bespoke stuff? Or are most people, like reaching for kind of a best practice and then just making slight tweaks here and there?

Josh: That is a hard question. It's all over the place. I see some teams that don't configure anything other than the recommended rules that sit for five years untouched. And then you have a bajillion ent disabled comments in files, and then you have teams where someone in my past that has oftentimes been me is really passionate and has the time.

And then you have these really nicely bespoke cocreated configs, but it's all over the place. There's no one trend I can spot.

Noel: . What do you recommend to teams that are kinda, going through this journey or even devs that have been there before, kind of going through it on a new project and like trying to keep that healthy. When you're looking at a project and [00:10:00] working on one, how do you think about winter rules?

Josh: . I think as a quick answer, use the recommended configs for all of the things that are relevant to you if you're, say, working on a next JS app. Enable the TypeScript, the React, the next JS rules, and so on the core esent recommended ones. Disable any rule that isn't good or relevant for you in your esent config with a comment explaining why.

If the reason you'd have to disable it is just, it has too many complaints. File a to do item to investigate whether you wanna re-enable it. Keep those nicely grouped and explained in your ESN config and go on from there. I think you don't want dev tooling ever to be obscure and confusing. You want it to be approachable and, oh, I'm a new team member.

I could read up on why people did things the way they did, and that's true for Eoin or any tool that you're going to use.

Noel: Yeah, that makes sense. I guess . When do you think it is like justifiable to go disable one of those default rules? I know it's always hard to like conjure concrete examples, but generally what's the pattern where it's okay, I could probably disable this rule globally [00:11:00] and add a comment.

Like, when is that? When is that usually happening?

Josh: Yeah, rules are inherently opinionated and single purpose, and sometimes that purpose just doesn't make sense for you. I'm in the background peeking at some of my projects. So , let's say that you enable The ENT rule, no inner declarations, which is one that flags function declarations inside other functions.

There are stylistic reasons why that might be a bad thing, but honestly, in a lot of code bases that's not super useful. So if you enable it on your code base and you see a lot of failures and you disagree with the red or yellow squiggly, that's a really good sign that if you disagree, you just don't use the rule.

It's not for 

you. 

Noel: Hey, just taking a quick pause here to read an ad for Log Rocket. , log Rocket offers session, replay, issue tracking, and product analytics to help you quickly surface and solve impactful issues affecting your user experience. With Log Rocket, you can find and solve issues faster, improve conversion and adoption, and spend more time building a better product.

You can try it for free@logrocket.com. 

Are there specific kinda like frameworks or [00:12:00] even just paradigms that you have seen that require more, general linter disabling just because Yeah, they have, I don't know, they're paradigm, they're general method of doing declarations and setting things up just is more opinionated and differs from what the default rule set recommends.

Josh: Not really actually. I'm sure that there are places that do this, but especially in the last couple years, the default recommended rule sets for both Esly and TypeScript BS L have been very intentionally honed to things that are universally applicable, or at least we try, especially in the upcoming V six of TypeScript BS sl we, take anything that people have been yelling at us about and just move it away from the recommended rules.

So I think. Legacy apps, this is a problem. We had an issue recently, Ashley, about someone who had a very large Jake code base that didn't play well with our floating promise detection rule. The rule that says you created a promise, but don't handle it. If it fails, something bad might happen. And if you're using a [00:13:00] legacy code base from, 10 years ago's practices and try to use a litter from today's recommended practices, there will be some mismatch.

Noel: , yeah, I could see that being particularly tough there. Okay, so circling back slightly, so you said that now the recommended rule sets will generally not have anything that does crop up. with the modern frameworks, common practices and stuff , Is there any fear then that , the default rule set is overly permissive?

Or say you're spinning up a new project, is there other rules that you might want to go look at that may be wise to enable early on to get, like good coverage, make sure code stays healthy.

Josh: Yeah, I think this is actually one of the bigger. Not problems, but lack of perfections in the ESL community that there are a lot of community plug-ins that are great that people just don't enable. For starters, neither njs nor remix, I'm gonna call them out rudely, I apologies. They're great frameworks.

Love 'em very much. Could not imagine life without them or similar things like Astro, but they don't enable type 50 Bs, SLS recommended rules. So that's a big one. Just right out of the box we've been talking to them in public trying to get that [00:14:00] enabled but also, I have this project this template, TypeScript node package where I'm just trying to set up all the things I would want in a typical, TypeScript node package.

And in my ESN config for the plugins list the list of community plugins. There are 1, 2, 3, 4, 5, 6, 7, like nine or 10 of them enabled. Which is nine plugins that I went out of my way to investigate and then gave me added value, like the regular expressions plugin that detects, exponential red xs.

That's work of the vast majority of people are not doing, and thus not getting benefit from, which is a little painful to see.

Noel: Yeah. Yeah. I have a suspicion that most of the time when somebody ends up looking, going and looking like seeking out a specific rule or looking for a plug in, that'll help them get configuration set up for something. It's like they've noticed some particular little pain point that they're like, that looks ugly.

I want to go fix that. , is that how you fell into most of these as well? Or are you more proactively seeking them out? Ooh, this is a good practice, I should, enable this plugin.

Josh: Yeah that's both what happened in my career and what happens with , myself included, the vast majority of Eoin [00:15:00] consumers, it's very reactive. I caused, or I saw an issue. I looked up how to fix the issue, or even I had a hunch that this is the thing you could solve with say Lin. Now, I enabled the thing to react to that.

I got into Lintering because I made this giant JavaScript code base, at least giant for me at the time, that had a bajillion bugs per line, and Lin was one of the ways to fix that.

Noel: If you do encounter one of these, , , what's the best method to search for a rule or like config that may help remedy it? Because I feel like that is like tricky to search for sometimes, right? If you're just trying to use Google, it's like hard to use these terms and there's lots of weird symbols involved and stuff a lot of the time.

How do you find those?

Josh: Yeah, there's actually a great repo I wanna shout out awesome ES lint. It's from someone named Dustin Specker. Shout out Dustin, who interestingly works in the exact opposite part of the stack is me. And yet we have this in common. It's just a giant list of awesome eoin plug-ins. So you can look up like, oh, I have a bug in regular expressions.

How do I prevent that? And you might get [00:16:00] eoin. But for setting up my template repo, I just looked through this giant list of plug-ins and on the ones that I thought were useful to me. Just opened a bunch of repos and new tabs and looked through each of them.

Noel: Oh, nice. Yeah, I see you on the contributor list there. You've done some work on. Awesome. Excellent.

Josh: That's how you know that I've used a thing because I've found a thing I want to contribute to in it. Yep.

Noel: that's a good, that's a good sign I think. Cool. So your talk. I guess kind of one more point on in this realm, your talk specifically is es lent in React. Is there something react specific there that you wanted to cover? Or is it mainly just your presets that you'd recommend setting up for a React project?

Josh: Yeah, it wasn't extremely specific to react other than I showed a React app using these things and bugs you could find in React App. I will say that if you're writing React, you should at the very least be using, ideally, the two React Eoin plugins, the Core React One and the React hooks one. If you're using a framework such as Next JF or Remix, you should be using their ESM plugin.

And for the vast majority of people writing React, you probably should be using your framework. In [00:17:00] general, I think that there are some really good core rules in all of those plugins that are useful for everyone and also just really informative about how to use, say, reactor, the framework. So definitely recommend those.

Noel: I think in general it's just like you gotta, you gotta take the few minutes getting the project set up. Yeah. Especially on these, .like if you expect the project . To go somewhere beyond this little toy app. It's worth a few minutes, get the winter going, you'll have fewer bugs, less headaches down the road.

Yeah. So let's, talk a little bit about type script and kind of maybe could you frame historically like how the type script es lent relationship plugin came to be? What that looked like in the early days of type script and what it looks like now.

Josh: Sure. I will note there were three common misconceptions that happened with me. The first two I mentioned are me working on linter type script. And the third is that I created this thing. I only joined projects after the created,

you know, like a vulture. 

At first there was ts Lin t Lent was a linter. Equivalence to Esly, but built specifically for type strip code. Instead of using the standard JavaScripts[00:18:00] representation of things of code called an asst or AB objects and text tree, it used the TypeScript asst abstracts and text three representation of code, which meant it was nice and fast, it was tailored for type scripts.

We liked it. It let us have the benefits of EO lent type world, but it meant every time a feature got added to one of those things, it would have to be re-implemented in the other Esent versus Tsin. And because especially years ago, TypeScript was a much smaller community than esent. Most of the time it was that Esent got a thing like a core feature or a nice community plugin.

And then at some point down the road, we might eventually get in TS link.

So short term TS link was great. Long-term, not so great because it wasn't as well featured or well supported. And now people use the word ts lin to refer to TypeScript lin or the types of compiler, and it's, it's a dead word. We should stop using it.

It's like one of my pet peeves, like using they versus their correctly, and it's not relevant to the vast majority of people, but it hurts me. So later down the road, the replacement for TS l [00:19:00] is a tool set called TypeScript. Slint. There's a long history of why it's called that and not other names.

But it is instead of a separate project, a set of tooling built on top of Esly that allows ES l to work effectively with TypeScript code. It's a parser that lets es l understand all this. Wacky new typescripts and text because it's not yet built into JavaScript yet with the question mark in quotes.

And then it's also a set of rules tailored to TypeScript and APIs to help you build Typescripts specific rules.

And that was created by James Henry and later on worked a lot on by Brad Zacker, a few other people. I now, I also joined as a maintainer here.

Noel: Nice. . I do feel inherently when going into type script projects there seems to generally be just like higher code health in I think generally in type languages, just because they're more regimented, there's like more patterns established.

Maybe there's fewer ways to do things a little bit just cuz like I feel having a type system and all that jazz puts one down paths that are a little more structured. Do you think that there is still [00:20:00] just as much a need for Lin in these typed languages or do you think like the role of the linter is slightly reduced?

Josh: The role, the linter is slightly reduced, but it is much more effective at the remaining role, and thus is even more useful, I would say. Yeah it's this awesome effect where The way that modern typed like today's type systems that are built on top of un typed languages, work tends to be a way of representing the way you were going to write code originally, like in type scripts, specifically the type system models, JavaScripts object types, let's say it models how you should think of code.

Things that are hard to do in type script are generally just hard to understand, hard to think about in general. As you said, yes, I agree. It biases you towards architectural patterns that are clear and understandable.

So that, that's part one of the answer.

I'll, I'll pause there 

Noel: yeah, that's a good, that's a good piece. But yeah tell me then about how does that then empower the winter? I. To 

be more powerful. . 

Josh: So there are some core EOS lent rules that are no [00:21:00] longer necessary in type two projects. For example, the no on deaf rule checks to make sure that if you're referring to a variable by name, it's a variable that's known to exist, which is a really useful good rule in JavaScript projects. But in TypeScript projects, you already have TypeScript for that, and it does a better job in eoin.

So some of the core parts of esent are no longer necessary in typescripts. But because you have the ability to refer to TypeScript syntax, and in the more powerful, though slower rules, use the TypeScript type checker, you can write much more powerful rules. You can write rules that detect whether, let's say you're using the proper for loop over an array versus an object.

Or you can detect that a promise has been created or a thing that creates a promise has been used in a way that, let's say, does not properly handle rejections for the promise. So you can detect much more insightful things about the code and catch much more subtle, difficult to understand bugs than if you were just using JavaScript on its own.

Noel: Yeah, exactly. And having the type script the compiler they're running, like it's doing all the deep type checking and all those [00:22:00] things that are definitely not probably in the purview, arguably in the purview of the lyncher. . If one is using type script, es lent rules that are all handled by the.

Type system. Are they like disabled by default? Like Is it easy to make sure that you only have one thing checking for these kinds of errors?

Josh: yeah. Our built-in default recommended rule sets. I'll. Four to six of them at this point. They in some way all disable the core ESM rules that don't make sense anymore, and we actually expose a standalone configuration if you just want to disable those rules and then reconfigure stuff on your own elsewhere.

Because we get a lot of, used to get a lot of complaints from people saying, this rule is unnecessary. Why am I still seeing it? So , one of our big goals, especially one of my personal goals for the project this year is to make it as easy as possible to configure this thing because it hasn't always been a hundred percent easy for larger projects.

Noel: Yeah. Yeah, I'm sure. , have there been any cases where I'm struggling to come up with a good example here, but where it's like there are rules where one might think [00:23:00] that type script would always be able to be checking for this or the type system would always be able like to check for this and handling it.

But the linter actually, there are cases where only the linter is detecting issues that you guys have run into.

Josh: Yeah, and this is cutting edge. This is a great question to ask because there's no agreement or standardization here. There are some parts of the TypeScript compiler options that enable things that arguably should be in the purview of a linter. Arguably, not necessarily correctly but yeah.

One example that we've seen recently is discussion around the exhaustive switch statements, area of rules. If you have a switch statement, should you have a case for each possibility? If it's a switch statement over a thing that is known to be a certain set of types, let's say you have a value that's one or two or three, and you have a case for one and two, and you're missing one for three, some people would argue this is fine and good.

That you shouldn't need to have an exhaustive switch statement. Other people would say no. The compiler or linter should verify that, Hey, you're missing a case here. This is probably a bug. You might have added a new type or something, and now you're [00:24:00] missing a case. And I strongly believe that is not in the purview of a compiler because a compiler should not be establishing opinions like whether you should have exhaustive switch statements.

And by the way, I'll note that's one of the. More jargon, heavy answers I've given in this interview because as we get into the more, compiler versus linter debates, it's gonna be a little more jargon heavy. And that's part of why I think the discussion is. Slow that it hasn't been talked about so much till recently because we've previously taken our time to establish the more baseline opinions, like what's a formatter versus a winter, and now we get to work on the fun stuff.

Like exactly where should different responsibilities fall within them.

Noel: I feel like your case statement example is a good one. I like pretty easy to conceptualize if you're not thinking too much about it. But I, I guess I, having spent significantly less time considering this than I'm sure you have, your point there seems, I.

Intuitive to me as well. It's it's valid code. Like it's fine. Nothing's gonna inherently break if this case statement doesn't handle such statement. Doesn't handle every potential case. [00:25:00] But I could see that being in the linter purview is there. Because yeah like the case , you talked about if I added a new option here, maybe I do care and always want to handle all of them.

That seems like the obvious one. Is there more, people on the other side of that, in the other camp, what is the typical argument that should be part of type script? Just that then it's easier to set up and it's there out of the box. Is that the main argument?

Josh: Yeah, that Typescripts should do these things that. May or may not be direct indicators of Code Health being off. Like TypeScript right now does have an option to check for unused locals or unused local variables and has an option to check for unused parameters. I personally, if I, king for a day would not put that in TypeScript itself, but the advantage of putting it in TypeScript is that it's core built into TypeScript, which means it's easier to set up.

It's I think, faster than if you were to just stand alone, use an Esent rule. I might be wrong there, and it's much more visible, like it's in the core TypeScript docs. People have to see that in their config and when they're reading the docs, they see it rather than some third party tool not actually [00:26:00] maintained by type scripts.

That happens to be popular in the community. Us.

Noel: Yeah. , it's hard to like draw that line . , it feels less weird to have the, type script compiler being like, Hey, you have an unused variable here. There's probably no real functional reason that would ever be happening.

So . It seems like that should be handled. , is that ever a perspective or a hat that you guys wear as is there ever a case where you would want that? Because like the switch statement example, there are valid logical cases where you would want to do nothing here.

It's harder for me to find those for like an unused variable declaration. So maybe that does belong in as part of the compiler, or do you think it should like we should never be crossing that line because they're just different kind of areas of concern.

Josh: Yeah, there are edge cases here. Two that come to mind are projects that set up type checking to block builds annoy me, but are more common than I want. I don't think it should ever be the case that you need to satisfy the type checker. In order to run something locally, you should be informed that hey, you have type errors.

But if I'm just hacking some stuff [00:27:00] together, like on a node c l I or something, I don't want to have to exhaustively fix all of my types of type errors, of which there may be quite a few. Knowing me,

Noel: I 

agree. 

Josh: It's annoying, 

Noel: Yeah, I'll like break my C I C D that's fine, but don't break my local development. Yeah, totally. 

Josh: exactly. Yeah. 

Which is by the way, something that I think we're, as an industry moving more close to that, that, what should be X C I C D versus what should break local builds. And I'm very pleased that you and I are in agreement. But also, like there are edge cases of unused locals or parameters, if you have abstract classes declaring an unused parameter on the base class per fun methods, is then gonna change whether the derived classes, the classes that extend your base class, how their functions are set up.

First of all, I don't personally use abstract classes often because I have moved away from that programming style for the most part. But there are people who use it and there are cases where it's relevant and good. So now even now we see something that seems to be very relevant and applicable actually is something you'd want to [00:28:00] have, control over in the winter.

Noel: Yeah, no, that's a good point. . Where is most of this kind of discussion and debate happening? Like which GitHub repo are these conversations happening in?

Josh: All over the place. I don't think there's any one place. ES Lent has a very good and popular discord, so does type scripts. We had touch with Es Lent recently set up ours. It's mostly people asking for help such as life. I'm not a community builder and do not know how to, build this up nor do I have much time.

I think Twitter is as a good place as long as Musk doesn't destroy it, that buffoon.

Noel: yeah. We'll see what happens. 

Josh: Yeah, it's all over the place though, and I think if you wanna get involved understanding the context here, there's no one best way overly, one only way to do it, I'd say search through some of the bigger issues or discussions on the Esly, TypeScript, Patrick Blin, GitHubs. Get up discussions and or Discords and you can start to get a feel for it.

Noel: Yeah. Nice. Yeah, I I would implore users, if you're struggling, get in the discords and search there. I feel like that's one of the big problems we have with these emerging communities is like there's a lot of work happening in Discords and people asking questions, but [00:29:00] none of it's indexed. You can't find anything when you search and it's like such a pain.

To find solutions to problems. Sometimes like in the past few weeks, I've been tried to bunch a new tech, like I'm bashing my head against something and I'm like I'll go look in the community's disc, like the most closely associated discord. It's yep, there it is. Four people ask the same question, but you gotta look in the discord.

Anyway, good. If anyone has a good solution to that, let us know. Get some cool repo. It's like dumping all of this discord discussion into like indexed public search things. I think that there'd be some utility there. Yeah. Is there anything else you'd implore listeners to, to check out or how they get involved?

If they'd like.

Josh: Yeah, I'd say use the preset configurations as starters and take on my strategy of enabling them disabling rules that don't make sense for you. And then looking at all the precept plugins definitely be active on the TypeScript Eslan issues Discussion. Discord we're working on a V6 that's gonna make the recommended rule sets even better.

I'm personally working on some performance stuff that [00:30:00] should make things faster, working with the TypeScript team with that one. Very excited. Shout out Jake Bailey. Yeah, get involved and think deeply. I think a lot of people online have a habit of making these absolutest statements like Lent or bad or type script good without understanding the why behind it.

And then you end up with these stupid discussions where people are just screaming at each other about how they're idiots and that's not healthy. So learn stuff before you discuss it and then come to me, or at least come to me if you want help learning.

Noel: Yeah. What programmers being strongly opinionated about something they haven't thought all the way through. Never. That never happens. Yeah. Cool. Thank you so much for coming on and chatting with me, Josh. It's been a pleasure.

Josh: Yeah. Thank you. This has been a pleasure. I really enjoyed this.