Supper Club × ESLint with Nicholas Zakas

I sure hope you're hungry.

Hoo. I'm starving.

Wash those hands, pull up a chair, and secure that feed bag, because it's time to listen to Scott Tolinski and Wes Bos attempt to use human language to converse with and pick the brains of other developers. I thought there was gonna be food, so buckle up and grab that old handle because this ride is going to get wild.

This is the Syntax Supper Club.

Welcome to Syntax. This is the podcast with the tastiest web development treats out there. Today, We have on the show Nicholas Zakas. He is the author of ESLint, the author of many JavaScript books. He's been around on the Internet for a long, long time in the JavaScript space. It's it's actually very interesting Doing this podcast and having people like Nicholas on because literally, I'll tell you a little story.

12, 13 years ago, I was a young buck going to interview at Google, and I said They're going to ask me things about computer science, and I don't know anything about computer science. So I spent a good part of the week Reviewing one of your blog posts or one of your Git repost called, like, computer science and JavaScript or something like that. And That was a long, long time ago, and it's it's kinda wild to have you on the podcast here so many years later.

So welcome. I'm glad you found that helpful. Yeah. That was I was going through a similar process when I wrote those blog posts and put up that GitHub repo of trying to refresh myself with computer science topics. And the best way I knew to do that was to redo it all in JavaScript. So I found that helpful.

Oh, that's awesome. Well, do you wanna give us a a quick rundown of, who you are and what you do? So

I am the creator of ESLint, which I'm assuming most people listening to this have heard of.

We're now going on 10 years.

Wow.

Of PS Lent, which is pretty crazy.

Before that, I spent a lot of time in Silicon Valley at different Companies at Yahoo and at Box, I've been working on open source pretty much since 2006, in different ways.

I've written or contributed to about a dozen different books related to JavaScript and web development.

And I also do coaching for software engineers.

So a very wide ranging Career and I first encountered JavaScript in, 1996 and kind of fell in love with it. And Never imagined it could be an entire career, but here we are. Yeah. That that's wild that,

You've been at the same language for for so very long, and you've never, like you look at some of the folks In the past of history who like, t j holowachuk and and whatnot, and they come up in JavaScript, and then they leave. You know? And it's funny to see that you've Stuck with it for for all this long. I'm sure we'll talk about that.

So let's get into talking about Just for everyone listening, we're going to start talking about ESLint, what it is, some of the new stuff coming to ESLint.

And then I I also really want to talk about, I know you do some coaching. And since you've been in the industry for so long, I think you have have some really good insights into not Just how to be a good coder, but, like, how do you interact on teams and and how do you manage an employee. Large repo and And all that stuff. So I'm I'm interested in hearing that kind of stuff as well. So

ESLint.

Right? It's the it's really the wool that everybody uses to evaluate code quality these days, and it it it you said it we're we're approaching 10 years And I remember back before ESLint everybody was using, JSLint or JSHint I think were the the 2 big ones.

What was the the catalyst that made you say I would prefer something different? And and and how, I guess what made you want to build ESLint and and how did the previous Versions of the same type of tool, you know, affect the discovery or the creation of ESLint.

I was A long time user of both JSLint and JSLint, and they were great.

Really, I think, Made a big difference for a lot of JavaScript developers, and I never thought at any point in time that I would Create my own limter because those seem to do the job pretty well.

Especially J. S. Hint, which was a little more open to Changes from the community and suggestions, it seemed like that was safe to use Pretty much whenever you wanted some help with your JavaScript.

What happened was a very specific bug that I ran into a box, which was say that was 2013.

And we still had a lot of customers using IE 6, IE 7.

And a bug had gotten out into production where this 1 customer had come back and said, nothing is working. That click, nothing is happening.

And after an investigation, what we found was that the Ajax requests, As they used to be called, we're not working at all in their browser.

And the reason for that was someone had used the native XML HTTP request object to make some requests.

And that normally is fine, except This particular customer had a network security policy that disabled active x objects.

And the native XML HTTP request object in IE seven was Actually, just a wrapper around the ActiveX object. It wasn't a native implementation, and so it killed that completely.

And you think, well, if you're supporting IE 7, why didn't you run into this problem before? And the answer is we did.

And we had a workaround for it, basically using a Flash movie shim that would let us do Requests even if active x objects were not allowed.

And so The question became, well, why were we not using that if we already solved this problem? And it was because it was a newer developer Who didn't know that that existed.

And as part of the postmortem, we were thinking about, well, How do we prevent this from happening again? Like, how do we make sure that everybody just knows don't use native XML HTTP request, Use this custom Flash movie instead.

And we just didn't have a good answer for it.

The best thing we could come up with as well, We'll set up a regular expression checker on JavaScript as it goes through, and that will flag it. And, of course, using regular expressions that are not syntax aware, lead to a lot of false positives.

And that really started me down this path of thinking about, okay, what do we really need to solve this problem? What we really need is to parse the JavaScript code and then look at the syntax and see if there's a reference to a global variable, XML HTTP request, and then flag that.

And

that really was what Started me down this path of investigating how to do something like that. Man, that that's wild. That was actually my next question is well, actually, first of all, I love hearing stories from the olden days when you use such word as native XML HTTP request. Like, you had to polyfill The XML HTTP request, like, it's wild that we we just did that with fetch. Right? And now we're at a point now where fetch is everywhere.

But my next question was just, like, how does how does ESLint even work? Like, how does it know when I'm doing specific things? So you're saying you you parse it, and that gives you what? Is that called an AST?

Yeah. So inside of ESLint, we use The parser, either the default parser that we ship with or a custom one that you've supplied in your configuration, And parses it into a structure called an abstract syntax tree or AST.

And then each of the rules traverses that tree and just looks at The nodes that it cares about and says, oh, this is a pattern I recognize and either it's good or it's bad, and then just outputs A warning related to that.

And so each of the rules is implementing a pattern called the visitor pattern That lets you visit different types of nodes that you care about. So not all rules care about all nodes.

But You can register which nodes that that particular rule cares about.

And as ESLint is traversing the tree, When it comes across one of those nodes that you care about, it calls a method in that particular rule.

So the rule can inspect it, do whatever it wants, and then decide if it wants to, emit a warning or not.

And and some examples of that might be, like, a very basic, like a shadow variable, where in upper scope, you have a variable called name. And then at a lower at a lower scope, you also have a variable called name. And those 2 There's a possible it's not a bug, but there's a possibility that you, the developer, could get mixed up and or not be able to reach the the outer scope variable. So it just it recognizes those types of things We'll throw up a an error or a warning depending on your configuration. Right? Yep.

That's exactly how it works. And in that case, There's actually some additional information that you need because these scopes are not necessarily represented in the AST.

Like, that's a concept. It's not part of the syntax. And so we actually do scope analysis As part of running ESLint on a file as well so that when we are traversing the AST, a rule can say, okay, give me the scope that's related to this particular node.

And That scope then contains things like variable declarations, variable references, and Stuff like that that you can use to implement that no shadow rule that you mentioned. Mhmm.

So these patterns like the visitor pattern, right, are are these things that that hold up to even, We know next gen versions of the ESLint and, I think we'll talk quite a bit more about whatever that becomes next or whatever the future of ESLint becomes. But Are are these patterns that you you still recommend for this type of thing? Yeah. These patterns aren't going to change

going forward.

They've withstood the test of time so far, and we have yet to come up with a better way of doing things.

As an interesting side note, the way that ESLint works is that it does a single traversal of the AST and runs all of your rules along that traversal.

A lot of Other tools that kind of came and went during ESLint's lifetime ended up with each rule doing its own traversal, Which is a lot slower.

And it's also why, ESLint Continue to be able to adapt because adding new rules didn't have the same sort of performance impact As adding new rules and other tools did. Oh,

I I'm gonna just throw a little question in here. How do you work on a project for 10 years and and still stay motivated to work on it? Like, this is An incredibly complex project being able traversing and understanding everything that's going on, and we haven't even touched, like, configs And sharing configs and mono repos and all that type of stuff like it. I'm sure it must be exhausting at at times to have to maintain it. Like, what's your secret here to be able to

Marathon a project like this. Yeah. It it's a lot. And, like, the longest that I have ever spent at a company was about 5 years when I was at Yahoo, so now I'm at double the amount of time of my longest job of working on ESLint.

And really, it's just I'm still curious.

I am curious about JavaScript as a language.

When the new features come out, I'm always digging through the specs, trying to figure out how stuff works.

I just I find it really interesting. To me, the evolution of JavaScript is the continuation of a story. It just it just keeps going and looking at how it's adapting and changing.

And then, In turn, figuring out how ESLint has to adapt and change Mhmm. To keep up with it is just Incredibly interesting to me. I find that I'm continuing to learn new things.

It Continues to send me in different directions, different things to investigate and different things to learn.

And at this point, it feels like JavaScript and ESLint are as much a part of my family

as, you know, my mom and my dad. Yeah. It's true because when you started this thing, promises did not exist. Async await did not exist.

Like, even the other day, I was using a new feature just called import assertions, where you in ES modules, you can import. ES modules were not a thing.

Importing JSON into an ES module is not a thing, but it recognized that I needed a, a plug in for that because it's not formalized yet. It it's amazing that it's been able to just, like, keep up where the language looks nothing like it did probably when it started.

Yeah. So to give you a snapshot of the JavaScript landscape when it first started, Most people were using Backbone and jQuery to create their web applications.

This was the era where JavaScript developers learned about the model view controller Yeah. Approach to architecting web apps. And everybody believed that that was the end all be all of how it'd be building web apps forever. Yeah.

And There were still conversations about whether, UMD module format was the right way to go, or if, you know, common JS was really a better way of doing it.

Node was pre one dot o at that point. I'm pretty sure it was around, but had not been around for all that long.

And, like, nobody had heard of Well, I I shouldn't say nobody had heard of React.

React was starting to gain some mindshare, but it seemed unlikely that it was going to knock off Backbone Mhmm. As the dominant way to build web applications.

It

was a very, very different world than we're in today. Yeah. I remember interviewing for so many jobs where it was like backbone and marionette. That's the, that's the whole stack you got to know marionette you got to know backbone.

How closely do you have to stay up on The proposals for JavaScript, like, at at what point does a proposal reach your radar as being something that you need to actually start thinking about in regards to ES So we pay pretty close attention

to the proposals once they get to stage 2.

So at stage 2 is when we really start looking at, okay, what is this shaping up to be? How will this affect ESLint.

Once it gets to stage 3, we start to have a pretty good idea about What we'll need to do in ESLint with regards to updating parsing, maybe updating scope analysis, Potentially adding new rules that help people understand how to use new syntax.

And once it gets to stage 4, that's when we actually start implementation.

Because of the way that we organize things by ECMA version, so which year did the thing get finalized in, We can't really start adding new syntax until we know which year specification it's going to end up in. So, generally, what happens is once something hits stage 3, we get a flurry of issues of people saying, hey. ESLint needs to start supporting this Because it just reached stage 3, and we always say, hey. That's great. Thanks for letting us know. Just gotta pump the brakes a little bit. That's not the way Not the way things work.

And we need to take the time, number 1, to make sure that it doesn't end up getting demoted back to stage too, which sometimes happens. Yeah. And sometimes that is a nontrivial change. And frankly, we just don't have the bandwidth To be implementing and then unimplementing and reimplementing things, Babble already does a fantastic job of keeping up With those early stage proposals, and if you wanna use that in ESLint, you can use the babble ESLint parser, Which is fantastic, and we'll give you access to all of those experimental features.

But we don't actually start implementing in the core Until stage 4 to make sure that we don't have to

undo and redo any of those changes as they come along. So let's talk I wanna talk about 2 things, which is sort of like next gen ESLint and what that looks like. Specifically, the first one is going to be the configs, and the second one is I I saw you tweet about this a couple of months ago as you're you're sort of looking into writing it for more languages than in Rust. So let's talk about the first one, which is the Big because the way we write JavaScript these days is is a lot different. Right? Like, we have monorepos and and whatnot. And I was specifically going down the rabbit hole of trying to tighten up my ESLint config. So I got a couple of plug ins, a couple of presets, and, when I ship it to one of my courses, it's 6 or 7 different pure installs, and and that's a pain in the butt. So I wanted to just, like, put it all into 1.

But as soon as you get 2 levels deep, it can't find it.

Tell us about the the pain of creating your own config It's system in JavaScript.

Yeah. The legacy of the config system in ESLint is Quite the tale of simplicity gone wrong.

Where When ESLint first started, I had a very simple idea about how config should work.

It was You have a config file that is your primary config file.

And then if you want to override any of those in a particular directory, you just Drop another config file into that directory, and that takes precedent.

And then ESLint, when you're linting a file, walks up the directory structure from that file and just merges each of the config files that it finds along the way.

And that was all that it was to begin with. There was no extends.

There was just one, file format .eslintrc.

That was it.

And that worked reasonably well.

The thing that I hadn't anticipated was that people would want to share configs across projects.

Because I was coming from a world of JS Hint where you just had, I just had a few rules that I Configured, and it was nothing to just copy and paste stuff in.

But the ESLint configs were starting to grow beyond what The JS Hint configs were.

And so one of the team members said, hey. Why don't we Copy what JSHint has, where JSHint had implemented this extends key inside of their config.

And, like, let's just do the same thing because it'll make it a lot easier. You won't have to worry about dropping configs in different directories, and It it'll just make life easier.

And so we went ahead and and implemented that.

And this was Actually, where I think we made the 1st mistake, which was instead of saying, okay, extends is the way that you will do configs from now on.

We added extends and kept the kind of directory based config system as well.

And that was where complexity started sneaking into the config system.

And next, I realized, hey.

If we are doing extends For local files, instead of just reading in the file and parsing it as JSON, We could just use require.

That would also read Jason.

And then we could actually implement configs as packages that could be shared on NPL.

And so we started with shareable configs at that point.

And this was where I made a bet that did not pay off, which was The way that npm worked then would continue to be the way that npm worked in the future.

And that was where we started with if shareable configs want to use Plug ins.

Then they need to list those plug ins as pure dependencies on the shareable config.

And that was such a minor issue at that point in time because npm automatically installed Pure dependencies. Oh, yeah. Just like any other dependencies.

And like, hey. That's the way NPM works.

We can piggyback on that.

We couldn't have it as regular dependencies because these were not JavaScript packages.

They were JSON packages.

And so inside JSON, you couldn't say require something and have that bubble up like you could with JavaScript.

So it had to be pure dependencies.

And little did we know That NPM, forget how long later it was, a couple years maybe, We'll just decide one day, oh, installing pure dependencies by default was a mistake. We're gonna stop doing that.

Sorry, everybody.

And we were kind of stuck.

Because, again, these were not JavaScript packages And so much as they were JSON or even YAML packages.

So we couldn't use The regular dependencies in these packages, we couldn't resolve those from inside of ESLint.

And so we started doing all kinds of awful things to try to better find these and shareable configs, including, basically, creating our own module resolution inside of ESLint, And then allowing you to kind of poke at that with command line flags to say, like, where plug ins should be searched for.

And it just turned into a horrible awful mess to where, like, 90% of the Help requests that we get on our Discord have to do with people's configs Not being able to find plug ins or not being able to find other configs.

And, you know, we kept Adding to the config system, more and more thinking that this would help get us out of This predicament.

And so we'd add something over here and something over there that would just tweak the config system a little bit.

We were never really stopping to say, okay, let's look at this holistically and see where we are.

And eventually, we just Got to this point where it it was just a giant ball of wires sticking out. Just a huge mess to where I just woke up 1 morning and just realized, like, we we just can't keep doing this.

It is an it is an Utter disaster, we're spending so much of our time helping people debug these config errors that they're getting. Like, there has to be a better way.

And so we started what turned out to be a multiyear process to redesign the Config system, basically, from the ground up, but trying to maintain as many of the core concepts as we could, So it wouldn't feel like a completely different config system to everyone.

And in 2022, we finally Released, the experimental version of our new config system that we call flat config.

And we're continuing to tweak it, But we are expecting that it's going to reach GA this year, 2023.

Oh, awesome. The I I converted just for kicks. I converted my my config over, and you provide fantastic, like, compatibility layer to convert old ones to the new ones. And I think I I think there's, like, 20 minutes, and I I had the whole thing converted over. So Fantastic design. I I don't envy anybody who has to build an entire config system. We had a whole show on config files, and we're asking ourselves, like, why maybe you can answer this. Why is there not like, why doesn't Node or NPM or someone step up to make A standard config system for all of these tools. And is it because they are so complex where they need to, like, layer on top of each other and have dependencies?

Yeah.

It's really hard to come up with a common format. And even where we find commonalities, There are usually small areas where things differ.

And that Makes it almost impossible to have something that works for everyone. So just as an example, Even if you just look in the realm of linters, if you look at what JS Hint does and what ESLint does, If you look back, there used to be a tool called TS Lint, which was TypeScript specific.

How they did configuration.

If you look at there used to be a tool called JSCS.

How they did configuration.

If you look at CSS lint, which I also co created back in the day, how that did configuration. If you look at style went, how that does configuration.

You can see similarities across all of those configuration files.

But There are enough things that are different that it's pretty easy to see you couldn't come up with something that could support Everything and still makes sense to users.

Right? Because, like, yes, you could actually create a config system that just allows Anything anyone could ever want, but then you lose some of the benefit of the config system, which Which is that it is predictable in some way.

Right? You don't have to configure, like, this Up top in one way and then this at the bottom, and it doesn't I see. Yeah. And

and it's so nice that when I just want my own Lent, my own config and my own project just simply extends West Boss. You know? Boom. You're up and running, and, like, it takes 2 seconds. You don't even have to make a file. You just put it in your package, Jason, if you want. So that's pretty good.

Let's talk about also what you what you see on the future of Yes, Flint. I know that you, like everybody else, are looking at rewriting in Rust.

Yeah. So I think that might have gotten Overblown on the interwebs.

We so because it is 10 years, and we have never done a significant rewrite of ESLint in those 10 years. Like, the way that ESLint works today is fundamentally the exact same way that it worked when it was first released.

And That's all well and good, but it has been holding us back from trying to do more things that we wanna do.

And so after 10 years, it seems like this is a good time to stop and think about, if we were going to write ESLint from scratch In 2023, what would that look like? And there is a discussion on the GitHub repo about this, Where I just sort of posted my big big brain dump of what I think ESLint should be now in 2023.

And Part of that is it needs to get faster because projects are getting larger and larger. And We haven't been able to keep up speed wise with some other tools that are out there. And as part of that, well, what would it look like if we Reroute part of ESLint in Rust.

And I think it's important to understand that The reason that a lot of JavaScript tools are being rewritten in Rust now is because they are Part of the normal developer workflow, and you want that to be as fast as possible, Especially when you're looking at transpiling files, whether it's TypeScript files or Flow files or anything else where you are writing some code that is not being delivered to the browser, And you want to transpile that into the form that will be delivered to the browser. And if you have to stop and wait for Type script and it takes like a minute every time to transpile your gigantic project.

That just kills your productivity.

And ESLint is not in that hot path for a lot of people during development.

It's usually either in your IDE as you're working, and that's fairly fast because it's just working on 1 file.

It's not transpiling anything, or maybe you do it on a pre commit, so you're just checking the files that you're checking in, or you're doing it as part of CI.

Like, these are not hot path as you're working on your code.

And so our moving to Rust or rewriting Parts of stuff in Rust is balanced against what do ESLint users need.

And the primary thing that ESLint users need is configurability.

Right? Like, you need to be able to customize it for your project. That is The killer feature of ESLint that allowed it to surpass JS Hint was JS Hint was not able to adapt Fast enough to the changing JavaScript landscape because it was built with its own parser That it wasn't capable of swapping out.

So any new feature had to be built into JSN. Uh-huh. ESLint doesn't have that problem.

We're able to just swap in and swap out parsers whenever we wanted. So we started with Esprema.

When development on Aspream has slowed, we forked it and created our own that we could just plug in.

And now something like 80% of everybody who's using ESLint is not using the default ESLint parser.

So The configurability is really the killer feature of ESLint that we cannot lose.

And when you're looking at rewriting ESLint in Rust, the first question to ask is, well, What happens to this entire ecosystem of ESLint plugins and rules and parsers that people are reliant on right now? Well, we can't get rid of those, which means that we really can't Rewrite the core of ESLint in another language, whether that's Rust or something else.

Because, fundamentally, we want to allow people to rules in JavaScript. Yeah.

And plug those into ESLint. Like, we just cannot lose the AI.

And There's plenty of evidence that this is true because there are actually multiple JavaScript linters written in Rust that have come up over the past 2 or 3 years, And they've been unable to gain any significant market share because how Do you transition from ESLint to another linter that doesn't support the rules and the plug ins that you need.

And so when we're talking about rewriting parts of Versus lint and Rust, what we're really talking about is, Can we create a natively compiled CLI that can offload Some of the generic stuff that ESLint does, maybe stuff with the file system, Maybe doing something with configuration.

Not entirely sure about that.

Maybe some type of parsing. Not entirely sure about that.

But can we leverage Rust to do some of the stuff natively and make The ES lends CLI faster by doing that.

And so one of the avenues that we're investigating right now is creating The CLI in Rust that embeds Deno, and then Deno is able to run The ES went JavaScript portions.

Yeah.

And the file system stuff can be done inside of Rust, potentially faster.

And then maybe we're able to take advantage of Rust threads To then paralyze some of the linting that ESLint is doing and achieve a speed up that way where we're not rewriting the core of ES lint and rust.

But we're doing a layer on top of what ES lint is today that Allows us to do faster linting.

That's super interesting. How do you feel about, in general, like, tools going the Rust route? Do do you feel like it is universally, they're going to be a performance increase by moving to a language like Rust Or is it just all hype? There's definitely a performance

increase when you are rewriting, say, something that is written in note Interest.

Like, there is just no comparison speed wise between the 2. Mhmm.

And so and I think that any place where you have a tool that's in your hot path for development, That is a really good candidate to rewrite that in Rust and speed that up. Because the last thing that you want is developers sitting around, Waiting for tools to run multiple times an hour.

And that's just a huge time sink.

And, like, stuff like ES builds totally makes sense.

Rewrite that in Rust.

Rewrite, webpack in Rust.

Rewrite transpilers in Rust, that all makes a ton of sense.

Where you run into trouble and where ESLint lives is in the area where you want to enable developers To quickly and easily customize the tool, in a language that they're familiar with. Like, if I start telling people, Hey. In order to write a rule for ESLint, you have to learn Rust.

You have to write that rule in Rust.

You have to compile a Rust package and deploy that Rust package.

That's a huge barrier to entry for a lot of people who are working on web apps or even Node. Js,

server side stuff. Yeah. I I find that as well with, like, Tori, which is, like, the kinda electron killer.

There's some simple stuff of configuring menus and whatnot. I'm starting to get it, but, like, man, do I wish that was in JavaScript? I would be so much faster.

You think about that. The reason why the ecosystem is so amazing is because so many people are comfortable and can build stuff and leverage the existing stuff in the space.

You said in a DM with with me that you're possibly looking at ESLint for more languages. Like, are we gonna see HTML, ESLint, CSS, ESLint.

So what I am working on currently is Allowing ESLint to parse and evaluate languages other than JavaScript.

And it's actually not all that difficult.

There's Long been a trend on Twitter where people would say, oh, I wish there was an ESLint for One I wish there was an ESLint for Jason. I wish there was an ESLint for HTML. I I wish there was an ESLint for YAML.

And one day, I was thinking about it. I said, well, why couldn't ESLint be the ESLint all of these languages.

Why does it need to be something else? Like, why do we need to keep creating these one off linting packages that more or less Keep copying what ESLint is doing. Like, that seems like a huge waste of developer time To reimplement a lot of what ESLint already does.

Configuration, Sharing plugins and packages, all we really need to do is figure out a way for ESLint To understand syntax trees that are not related to JavaScript, And then pull out all the JavaScript specific pieces into its own package such that we can plug JavaScript in like we can plug in any other language.

And so I'm actively working on right now This is what I call the languages plug ins proposal that would allow us to do that. And so what we are looking at is, Can we define what a language is in terms of you parse a language into this syntax tree, Then you need to know how to traverse that syntax tree.

You need to execute rules on that tree, Do auto fixing like we do now. Mhmm.

And allow that all to be configured from within the same config file.

And the RFC is already up if people wanna go check that out In the ESLint RFCs repo, and I've started prototyping this.

And the plan is that We are not going to create language plug ins for every language that is out there. Right? That that would just be Way too much bandwidth Mhmm. For what the team is able to maintain.

But much like we allow plug ins, allow parsers to be plugged in, We also want to allow languages to be plugged in.

So if you are really interested in creating A ESLint plug in for Yevl, you can do that. There'll be a guide that walks you through.

Here are the steps that you need to do in order to create, an ESLint plug in so that we can lint YAML files.

And this is another thing where we know that people wanna do this because of some of the stuff that already exists out there. Mhmm. Like, there is a GraphQL ESLint

Yeah. Yeah.

Package. And they do Tremendous things to make ESLint be able to parse and understand GraphQL.

And The way that they do that is basically by making an, an AST that looks like a JavaScript. Uh-huh. Which is just Insane. Yeah. Right. Yeah. There's there's no reason that you should have to try and make other languages look like JavaScript To trick ESLint into limping it.

And so we want to provide this toolkit so the folks who are doing GraphQL ESLint can create a proper plug in that treats GraphQL as GraphQL and not as JavaScript, and allow people to more easily work with GraphQL that way.

And we're gonna Start out by creating a JSON plug in that allows you to lint JSON files because, Both JS Lint and JS Hint actually can also lint JSON files.

And that's one of the questions and And bits of confusion that we get from newcomers to ES Lint is, oh, I thought this would lend Jason Biles.

Sorry. It doesn't.

Although there is A JSON plug in that once again makes JSON look like Oh, yeah.

For ESLint. So you can kind of hack that in, but Seems like it's time for for full first class support. Love it. So we'll create, a JSON language plug in.

We will create a markdown language plug in.

And then after that, we are just going to let The community and the ecosystem grow in whatever way that it wants to grow. But we feel like it's important to have these, model language plug ins. So if people get stuck, we can say, hey. Go check out what we did for Jason. Go check out what we did for Markdown.

Follow those as examples and go from there. Awesome.

Let's move into the the coaching stuff. I don't wanna Spent too much time on ESLIX. I know you wanted to talk about the the coaching as well.

So this was a very interesting quote on your website. Is It says at a certain point, you stop being judged for your technical skills and start being judged on how you work with people. So I thought that was Really interesting because you're probably a pretty good JavaScript developer by now. Right? And at a certain point, I think in your career, You get good enough at at your actual coding abilities, but there's a lot of room in your career to grow in terms of How you work with people. So is that kinda what you're focusing on here? Or or tell us about your coaching.

Yeah. That's exactly it. And that quote was actually from one of my mentors, back in the day, when I was just saying, no. Nobody's telling me, like, how do I get promoted? How do I get to the next level? Like, what do I gotta do? And he just very plainly said, look, you can't keep thinking that churning out more and better code is the way that You're going to get ahead in your career.

Like, basically, once you've been in tech for, like, 5 years, People kind of assume that you know how to write code. Yeah. Like, it it's it's not a mystery as to whether you can ship a product.

Alright. Getting stuff out, like, tests pass, websites work, people are using it, that's pretty much the base level of knowledge that you need. And during those 1st 5 years, you really need to focus on learning how to write production code.

And that is You are working on a team with other people.

You don't own all of the code yourself.

You have Time lines, you have deliverables. You're learning how to break down large problems into small tasks that you can manage.

Maybe you're learning, how to do scrum or kanban, but generally, how to organize efforts around building software.

And the best way to learn that is with the senior members on your team. Like, they've been there. They've done that. They're gonna help you out along the way. They're gonna review your code. They're gonna help you ship. But once you get past that point, that is where Things start to get more difficult. And I recognize this very early in my career as well because I looked around, and I was like, wait a second.

There are senior software engineers who are 25, and there are senior software engineers who are 45.

What happened? Like, why did people stay at that level And not continue to progress.

And that was when this conversation with my mentor really opened my eyes. It's like, oh, wait a second.

No. This is like being the quarterback on a football team And then becoming a coach.

Right? There there's a part where You are taken off the field, and you are not actually the one doing most of the scoring, Delivering most of the features.

You're on the sidelines helping to organize that effort.

And that is a point where a lot of software engineers tend to get stuck Because nobody tells them this.

Nobody is letting them know that this is the next step in your progression.

And, like, I like to say that Nobody becomes a software engineer because they want to be dealing with people all day every day. Yeah. I that's not Why we're doing it? Like, we like being in our desk, head down, just banging away our keyboard.

And yet, we get to this certain point where that's just not enough anymore. Mhmm. And you need to start Switching your mindset from I need to keep learning more technical stuff to I need to start learning how to be a leader.

I need to start learning how to communicate better with people.

I need to start learning how to manage my manager And how to interact with the executives and the leaders of the company to help them Understand the larger technical challenges and opportunities that we have.

That that's fascinating because That's amazing.

Like, if I look at at you, I'm sure you write a lot of code, but you also are Maintaining some of the most busy GitHub issues and project planning and and taking time to create RFCs and ponder How should we approach this type of thing? Right? Like, there's this whole another side of it. So is that management, or is that just like Is that another level above a senior developer?

I think the answer is that it's both.

And there are some managers who will do that, But there are also some tech leads that will do that. And this is the other thing that I think a lot of folks don't understand is that The further up you get in the IC track, the more nebulous your job becomes, The less well defined it actually becomes.

And you need to work to figure out What your role is gonna be.

And in some cases, that will be, hey, I need to be putting together RFCs or tech specs.

In some cases, that will be, I need to do some project planning and project management.

In some cases, that will be needing to Present your ideas to management in order to get, you know, a team created or a project funded Or something like that.

But those are not the skills that You developed probably from college where you were majoring in computer science, or even if you were majoring in something else, You are probably not majoring in this type of leadership and this type of communication.

And Making that pivot is difficult, but can also be incredibly rewarding. And another one of my mentors Told this to me one time that, you know, up until that point, you know, you're 5, 6, 7 years in your career, You're being judged on your output.

That's what your annual reviews are based on. That's what your salary is based on. That's what your promotions are based on.

But after that, you are really more judged as what he called a multiplier.

Which is, can you help make the other people around you better? Are you able to double the productivity of the Five people on your team.

And, therefore, even though you are not writing as much code and delivering as much code, The team as a whole is delivering far more, and that's because of you.