02:15 - Jamund Ferguson Introduction

02:47 - Lint (Background)

04:48 - Keeping ESLint Up-to-date

08:09 - Abstract Syntax Tree (ASTs)

13:28 - Using Lint Tools

20:42 - Are there a downsides to linting?

23:40 - Establishing Rules

25:12 - Cool ESLint Features

30:45 - How ESLint Works Internally

40:07 - Getting Started with Linting

43:03 - Autofixer 

44:41 - Plugins

46:47 - Linter Feedback From the Panel

Picks

Mozilla (AJ)
We Will All Be Game Programmers (Aimee)
Search Inside Yourself: The Unexpected Path to Achieving Success, Happiness (and World Peace) by Chade-Meng Tan (Aimee)
Good Mythical Morning (Dave)
Salt Lake City (Dave)
BB King Calls This One Of His Best Performances (Jamison)
json-server (Jamison)
Austenland (Joe)
Supergirl (Joe)
A Short History of Nearly Everything by Bill Bryson (Jamund)
The Book of Mormon (Jamund)

 

 

 

 

 

Special Guest: Jamund Ferguson.

 

Hello everybody and welcome to the JavaScript Jabber episode 162. Today on our panel we have Jamison Dance.

Hello, friends.

Dave Smith.

Hey, everybody

Aimee Knight.

Hello.

And I’m Joe Eames, your host. And as our very special guest today we have Jamund Ferguson

Hey!

[Chuckles] Awesome. Well, that’s the most excited guest I think we’ve ever had.

Everybody say, “Hey!”

[Chuckles] Are you waving your hands in the air like you just don’t care?

A little bit.

Nonstop.

So Jamund, we are here to talk about ESLint. Could you give us a little bit of background about yourself and your involvement with ESLint?

Oh, thanks so much. I am a JavaScript programmer. I’ve been programming JavaScript for a couple of years now. And for some reason I care a lot about things being consistent. And I care a lot about catching dumb mistakes. And linter tools like JSHint and ESLint help us catch those mistakes pretty easily.

So, I became a fan of linters a couple of years ago when I was working at a company called oDesk. I was working remotely from Utah and I worked with a big remote team. And I was kind of a UI architect. And so, I built all these components for all the teams across the world to use. And people would be working on them and I’d want to try to find ways to enforce code quality. And at the time I believe we were using JSLint. And we upgraded to JSHint which added more flexibility. But I was really searching for a better way to enforce standards across a large codebase, to enforce a whole bunch of different rules, to provide custom rules that just made sense for our team.

And so, I initially was really trying to understand how to improve JSHint and add additional rules. But it was a really complicated process. And so, when Nicholas Zakas came out a couple of years ago now with ESLint which was this great tool for helping look at JavaScript, I got really excited and started contributing right away.

Why is it called lint? [Chuckles]

Besides, did you get it out of a dryer?

Yeah, I mean basically. I actually have no idea. I think there’s this historical source of these tools that have been… there’s the Lint program I believe for C that was invented probably in the 60s, 70s? And it’s just been around forever, the linting. And there was really the first linter though for JavaScript is JSLint by Douglas Crockford. And Douglas Crockford worked with me at PayPal. And he’s a really nice guy. I don’t know why people like to make fun of him. He’s awesome. But the tool is very opinionated. And I think that put a lot of people off. It was around 10 years before any other tool. But it still, eventually people got fed up with it being maybe too opinionated. And so, they started looking to other tools. And JSHint for a long time filled that gap.

Cool.

Yeah.

We’ve been using ESLint for a while at work. And it’s really interesting watching it evolve. There are all these different competing tools for JavaScript. You have Babel to allow you to use the new ES6 and ES7, ES whatever features. And there are things like Flow and TypeScript that add typing to JavaScript. And you end up with this mishmash of a ton of different tools that are all trying to change what your JavaScript looks like. How does ESLint work in this situation where the language itself is evolving? And people are always building new things on top of the language that aren’t in the language itself.

Yeah. It’s really hard for contributors like myself [chuckles] because you build something and it works to a certain extent. And then all of a sudden a new language feature comes up and all of a sudden it doesn’t work. So for example, we have a rule that will check if you have unused variables. And then, well the language adds destructuring. And all of a sudden we weren’t accounting for those variables being unused. And we had to modify for that or adjust for that. And so, it’s a tricky process.

There’s a whole suite of tools. There’s a whole suite of tools out there built on Esprima, this parser that was created by Ariya Hidayat who created also PhantomJS. And this parser was created in JavaScript to parse JavaScript. And it created this explosion of amazing static analysis tools. And initially, Esprima targeted ES5. And so, all the stuff you were talking about just didn’t work. And that’s where eventually ESLint decided to fork Esprima and create its own parser called Espree, which then added ES6 support. And that worked really well. And I worked a lot on adding ES6 support to Espree because I’m really excited about ES6. I also use Babel here at work at PayPal. And we do a lot of fun stuff with ES6. And I was giving talks about ES6.

And I had to just, for a while I was disabling linting. There was no checking on any of those ES6 files. And I felt really silly because I really enjoyed using linting and it’s really important. And so, we ended up having to add this functionality to Espree. Well then Babel comes along and decides that it’s also going to support candidates for ES 2016 and further experimental functions. And so, now even our ES6 support which made it into Espree doesn’t cut it for, for example async and await and a lot of the really exciting cutting edge language features that I’m sure you’re thinking about using all the time at your cool startup.

So, what we’re having to do and what ESLint did which I thought was really clever was they allowed it so that you could swap out the parser. So, if you don’t want to use Espree you could punch in the Babel parser. And so, I think his name is Sebastian from Babel created babel-eslint which is basically a custom parser that uses the Babel core stuff and then converts it into a format that works with ESLint. So, it is a bit of a tradeoff. I think sticking with the core ESLint functionality which is pretty comprehensive for ES6 works really well. But if you want to use cutting edge stuff, ES7 or ES 2016 and beyond proposals, you can try the babel-eslint parser. I think this a great win for ESLint because none of the other Lint tools were able to so quickly adopt these new technologies.

So, we’re talking about Esprima now a little bit. Before we go too far, can you go over what an abstract syntax tree is? Because that is used a lot when we’re talking about this and I think maybe not everyone’s familiar with that.

Just a bit, yeah. I think probably a lot of us are familiar with that. I’m a little bit familiar with it. I went to school in environmental planning. And so, I learned about different kind of trees.

And so, when I…

[Chuckles] That’s so awesome.

When I started caring a lot about rules and linting and code quality, I was quickly really… I hit this point. And I think in the last couple of years, maybe a lot of people have felt this way, that I’d always thought that I could skate by as a UI developer just by knowing enough about the DOM and enough about CSS and enough about JavaScript to build cool things and I didn’t really have to worry about computer science. I thought computer science was for backend programmers. Not even Node programmers. Like some kind of C++ programmers that I didn’t really talk to very often.

And what I learned with a lot of the stuff coming out of React and a lot of stuff coming frankly from Angular and a lot of the newest frameworks, basically a lot of stuff coming out of Facebook and Google and big companies that hire a lot of computer science people, is that computer science is really relevant to UI engineering. And the way that Esprima works, as a parser it converts the code, the JavaScript code that you might have in a file, into a tree. It’s called an abstract syntax tree. And it’s a computer science term that basically refers to, in JavaScript it’s just a giant JavaScript object that has nodes in that tree that represent each and everything that you’re doing in that file. So, it’s really hard to explain without pictures, basically. But it’s essentially a data structure that represents the meaning of the code that you have.

So, if I said ‘var a = 10’ the abstract syntax tree would show me that I have a variable declaration. It would show me then that I was referring to a variable named ‘a’ and that I was setting that equal to 10. And that would be displayed, if you wanted to visualize it, as a tree, in a tree structure, in terms of the data format. A tree, not actually like a Christmas tree which I think would be fun.

Why is it a tree structure and not just a flat list? If my program is nothing but a series of tokens, why is it that it’s represented as a tree for tools like JSHint and ESLint?

That’s an interesting question. So, as far as I understand it, actually most of all our programs have nested structures. So, you have a function and then inside that function there’s more things and more things. And so, actually a tree structure works pretty well. So, or if you have, imagine an if statement and then inside the if statement there’s the if-else conditionals in it. And it works really well to represent it as a tree. As well with the tree, you can skip over things that you don’t want. You don’t have to go and see this happens and that happens and that happens and that happens. You can look at each node and decide if you want to dive further into that node. So, I see a function declaration. Do I want to dive in and see what’s happening in that function or do I want to skip to the next thing that happens?

I think imagining it like just a JavaScript object for people who don’t have something in front of them to look at, that’s the best way to think of it.

Yeah. Think of a JavaScript object and it just has nodes or sub-objects inside that object for every single type of thing that happens. So, you declare a variable, there’s something. You have an if statement, there’s another object that contains all the information about what happens inside that if statement. So, you turn your programming language into actual code or almost basically JSON that represents the code. And this abstract syntax tree is powerful stuff, because once you’ve converted your code, the human-readable code, sort of [chuckles] (with JavaScript it’s sort of human-readable code), into this tree you can manipulate it using standard computer programming stuff, standard JavaScript. And you can transform that tree into something different and then regenerate the code for that tree.

So, you might think, “Why would I do that if I’m not crazy?” And the answer is you would do that a lot. You would do that if you were creating something like Babel which converts ES6 to ES5. So, that reads in an ES6 code into a syntax tree and then takes the representation in the tree of that code and converts it into ES5 output. You’ll also do the same thing if you’ve ever used Browserify transforms or if you’re using Webpack loaders. They take in code. They may convert that into a tree, modify that tree, and then output code again on the other side. It’s pretty cool. I feel like it’s some kind of wizardry, honestly, manipulating ASTs. Because you’re really taking something that seems so static, it’s the code of your page. And you can actually manipulate it in a safe way and then regenerate code on the other side. It’s fantastic.

Minification does this too, right?

Oh, minification, yeah. So, really the good minifiers and really Uglify I think… when Uglify came out it was this awesome improvement on minification because it converted your code to an AST, an abstract syntax tree. And then it was able to do such better analysis on what it could collapse or hide or remove or change, because it was able to see the whole thing in terms of code instead of just a bunch of strings or tokens as you referred to them. It’s a much more durable way to manipulate stuff.

I want to change the subject a little bit and talk about linters in the abstract. I have a friend who says that he really doesn’t like linting because he likes being able to tell who wrote the code. He likes that feel where half of it has semicolons because then you know the person that doesn’t use semicolons wrote the other half.

What? That’s what ‘git blame’ is for.

Yeah. Well…

I don’t know. I think that’s facetious. But you could say that linting is limiting your expressiveness and freedom and…

Oh my goodness. Oh my goodness. [Laughter]

Code is art.

Someone’s flipping out over there.

But the function is the art. The art is the piece where it goes from unorganized mess on the internet into something on somebody’s display. That is the art. The way you write you freaking code is not art. If it’s JavaScript, write it the JavaScript way. If it’s Go, write the Go way.

Yeah. What I’m getting at is it can feel restrictive, right? And there’s…

Is that how you feel, Jamison?

It’s not 100% a good thing, right? Nothing is purely amazing, right? There is some tradeoff with saying we’re going to…

Except you, Jamison.

Except what? [Chuckles]

You.

Oh.

There’s one thing that’s 100% good.

Yes, I…

Jamison.

I’m glad you think I represent all that is good in the universe. Thank you. [Chuckles]

I didn’t say all that was good.

Oh, just some. Okay. But anyways…

Yeah.

I’ll comment on this.

What are the tradeoffs?

Because it’s, this is a really interesting question. So, you might think, like I love ESLint and that’s true. Therefore, I use it on all my projects. And that’s not actually true. I like to write sloppy code sometimes. And it’s fun. And I use that on when I’m doing personal projects. I’ll just throw together some sloppy code. It’s fast. It’s fun. It’s cool. Where linting really comes in handy is when you’re working with a team. And I take issue with your friend’s comment about, “Oh, I like to know who’s working on what,” or whatever it may be. I think when you’re working with a team the context switching that can happen if you’re trying to look at code that’s so radically different from another piece of the same code, it can be extremely jarring.

I’ve dealt with that a lot here at PayPal where we have a lot of people working on our codebase. Right now I’m working on the send money team. So, if you go to Send Money with PayPal and you don’t like it you can come talk to me about it. I’ll try to make it better for you. But there’s a lot of… it’s a pretty big product and we have a lot people working on that. There’s a whole bunch of different engineers that have different backgrounds. Some of them come from a Java background. And many are UI engineers. They don’t have real intense JavaScript experience. And so, we have this huge amount of people, hundreds of people that are working throughout our code here. And yeah, when people come with very different backgrounds and write code in very different styles, it may be interesting from an anthropological [chuckles] point of view or some sort of sociological point of view. But it can be really difficult. The context switching costs are high.

I’ll give you a specific example of where linting helps a lot. So, in Java it’s really common to throw strings. You can throw a string in Java if there’s an error and it will handle that nicely for you. But in JavaScript we usually throw error objects. We throw error objects because in JavaScript that will give you a stack trace. Both in Node and in most browsers you’ll get a stack trace so you can see where something went wrong. Well, if you throw a string you’re going to be in a lot of trouble in JavaScript. And we ran into this problem in Node where in one of our modules there was string throwing going on, which is very naughty. And it was really frustrating. And I could easily see how maybe a Java engineer might have thought that was a good idea. And where a lint tool can be really helpful is helping us avoid making really bad mistakes.

So, there are two aspects to linting which maybe I’ll talk about now. There’s the, “Can we standardize code style and make sure that people write things that look the same?” And then there’s, “Can we catch bad mistakes that people are making?” And…

So, there seems to be a separate project for the first one, right? That JS Style or something has emerged.

So, JSCS yeah.

Oh, JSCS.

JSCS is a really interesting project in that it tries to let you wholesale use an existing style guide. So, you can go to the Airbnb style guide and just enable that style guide. And the JSCS project includes the ability to just select one of 20 different style guides and enforce those style rules in your app. And I think JSCS and ESLint came about at the same time. I think they were both running up into some issues with JSHint, its limitations, its lack of flexibility, ultimately. And where ESLint started off was Nicholas wanted to be able to allow teams to write custom rules, rules that no one else cared about except for your little team. Maybe you wanted all your variables to start with a dollar sign, or you wanted your team to restrict the usage of jQuery in certain files, or whatever it may be.

JSHint was extremely difficult to change. And ESLint decided to go down the path of, “Hey, let’s make it really easy to allow people to write custom rules.” JSCS said, “Hey, we really want to focus on style rules.” And at the time, Anton who was running the JSHint project said, “You know what? Style rules aren’t that exciting to me. I really want to focus on syntax and making sure people aren’t writing bugs.” And so, he sort of said, “Alright JSCS, why don’t you just take over and do any style stuff?” And he started sending people that are looking to JSHint to do that to JSCS. And so, that project really started thriving. And at the same time that ESLint got off the ground.

But the thing is ESLint actually does all the same stuff that JSCS does. It can do all the same style rules, almost every one. And we’ve just added the ability to do something called extends where you can extend an existing style guide. So, you could ‘npm install’ some set of rules and you could extend that rule set locally. So, you can basically ‘npm install’ any style guide out there and start using that. So, this is where JSCS is in some ways, the ESLint folks like me think that JSCS could pretty much be handled with ESLint. They really started with different goals in mind. And so, I totally see why both are successful, but pretty much equally successful. They’re both really popular projects.

So, I want to go back a little bit to this point about…

Yes, let’s go back there.

[Laughs] About people… linting either eliminating your freedom of expression or standardizing, right? I kind of feel like, maybe I’ve got a unique viewpoint here, but I don’t think it really does anything. It does neither, because I don’t feel like it limits my freedom of expression. And when you’re writing code, how you write that code, the linter is such a very, very small piece of restriction that really doesn’t take away that much ability to be expressive. So, the idea that one, it standardizes the format of code I think is silly, because I don’t think a linter can do that with the very, very, very few things it does. Like you said, whether you got semicolons or you don’t have semicolons is such a gross piece of what a person’s style is when they write code. Or catching errors obviously is entirely different. So, I think that’s, I find that to be kind of almost a nonsensical argument.

Oh, I don’t know. I don’t know. Oh, go ahead.

I think I didn’t make my point clearly. I was using that as a stand-in for, what are the downsides of linting? Or is there anything that gets harder when you start using a linter? I agree that I don’t think that’s a huge downside to it. But is there a downside to linting I think is probably my [broader question].

Ooh, good question. What’s the downside to linting?

Yeah, or is it just 100% everyone should do it all the time? It will only make everything better.

[Laughs] You know, like I said, I think it’s fun to be sloppy sometimes if you’re working on small stuff and just throw something out there and it’s fine. Linting adds a certain formality to your code. And there’s a setup cost. There’s also a cost with regard to the tooling. And you kind of hinted at this earlier. But we’ve got ESLint plugins for Atom, Sublime, and WebStorm. So, you can have your linter hooked into there. You may have it as part of your continuous integration setup. We use it with the Grub plugin, with ESLint. But it adds all these extra steps. And you might start to say to yourself, “Do you really need to block a build because you didn’t put a newline above a comment”? This level of particularity, it can add overhead to your project and overhead to getting things done.

I think it’s useful on a team setting. And I think for many small projects it may be useful if you’re sharing that code or you have some… there are some other people depending on your code. But it definitely for the most part can… it adds some overhead in terms of thinking about it. And a lot of people, the way that we have lint set up, it’s usually done as a pre-commit hook here. And so, a lot of times people will code something in their way and then the pre-commit hook will run. And they’ll have to change a bunch of things. And it does add a certain level of frustration. There’s also a bit of ego around, “I like this rule.”

So, I’m the ESLint champion around PayPal basically, because I think it’s fantastic. But I’ll decide on a rule and I’ll just set it. And other people might disagree to the choice that I’ve made. And well, for the most part most people are cool with it. It can be a little bit of a conflict sometimes. I don’t like… I don’t know. If I didn’t like semicolons or maybe I don’t like some way of doing something somewhere, especially with stylistic things, some people really have strong opinions about that stuff. And so, it can cause conflict. It’s not perfect. It’s not a panacea. But again, for any time you’re working with a team or you’re sharing code with other people, I think it’s totally essential.

Sure, that makes sense.

And I say the biggest problem with linting is the social issue. I’ve had trouble on the Raspberry Pi. It takes a long time to actually run the lint process. So, I actually turn it off when I’m doing it there because the environment just isn’t powerful enough to give me the speed that I want on the feedback loop.

There you go.

But the social problem of the fights and the arguments and the, “This is better,” and, “That is better,” and it’s just all so stupid. It’s like, the purpose of the tool is, “Let’s write better code that doesn’t break our product for our customers.” And it turns into this, “Well, I like it when things are purple.” [Chuckles]

Yeah, exactly. So, this is where actually linting is extremely helpful. So, I started, when the ES6 support coming out, I started working on a few rules. For example, generator star spacing. Let’s decide before anyone starts writing generators in our project where the star should go, just because I know someone’s going to get mad. And they’re going to move all the stars to the way they like it. And having the rules in lint, it gives us this baseline of we don’t need to argue about this anymore. This is something that’s already been decided and there’s no complaining about it because it’s already in the ruleset. So, for the most part I think having a linter actually reduces those arguments because it’s already set.

One of the biggest downsides I’ve seen with JSHint previously and to some extent until recently ESLint is that it didn’t cover enough things that people were opinionated about. And so, we have rules in our internal style guide around spacing or newlines around comments. But until probably next week, ESLint isn’t going to have that rule. I’m working on it right now to make sure that you have a newline above comments and stuff like that. So, it helps actually squash a lot of debates and a lot of time that gets wasted on arguing about what the best way things should be.

Would you call it a bikeshed deterrent?

Absolutely a bikeshed deterrent, because people have these debates anyway. But if you have a rule and you can enforce consistency, I think almost always the argument of consistency is better than [inaudible].

Yeah. I care about style, but I care way more about a style being consistent than my personal style. I’d be willing to do things that I disagree with if everyone does them the same way.

Amen, amen.

Right, right.

So, we talked a little bit about the disadvantages of linting, tradeoffs I guess you could say.

Sure.

Tell us some of the cool stuff you get because you use a linter. So for example, I’ve considered linting to be in the category generally of static analysis. And there are all kinds of static analysis tools for different languages and stuff. But some of them can even do crazy stuff like before you even run your code it can say, “Hey, you probably have a memory leak here,” something like that.

Not so much in JavaScript necessarily. But what kind of cool stuff can ESLint do?

That’s a great question. ESLint can do amazing things. And I think it’s really good. And I hope all people will after the show just go and download it and replace the other linters. Some of my favorite things that it can do, or at least some of my favorite rules, and this is one that I think… I’m trying to think back. I think it might have actually been inspired by Jamison. He posted something two years ago on Twitter.

Oh, the error callback thing.

Yes! About how [inaudible]

Yeah, this is my great shining contribution to ESLint.

It was actually my shining contribution.

I complain about something.

Thank you very much. [Laughs]

No, my contribution was getting you to contribute.

[Laughs] Yeah, exactly.

Because management.

Meta-contribution.

Yeah, so Jamison complains like, oh it’s so annoying in Node. You have to always remember to callback, if you have an error from a callback you’re always supposed to check for that error and then return with a callback with that error. And this is something that bites a lot of people. I think there was a recent bug in IO.js actually where someone had left this out or something like that. I’ve seen it a lot in many projects. We’ve had to deal with it before, too. It often leads to errors where for example in Node you may try to send your HTTP headers twice and it can crash your Express server, for example. So, the ‘no callback error’ rule will check to say, “Hey, you forgot to handle this error coming back from a callback. You should do something about that.” I think that’s huge. Another one that I think is really nice…

Hey, question.

Oh, go ahead.

How does ESLint know that you are in the Node environment and this particular callback is one of those callbacks?

[Sighs] You know, I wish it were magic. It’s not magic. What we had to do was basically we had to assume certain things. And you configure some of this. So for example, most projects have certain conventions around that they always call an error ‘err’ or ‘error’. And there’s actually a rule that lets you try to enforce the naming on this stuff as well. So, the ‘no callback error’ rule, what it’ll do is it’ll say if you ever have a function, if you’re ever inside of a function and it takes as the first argument ‘err’ or ‘error’ or anything similar to that or ‘e’, it will assume that that’s an error. And if you don’t do anything with that, if it goes through the function, it looks through the syntax tree and says, “Was this error variable ever used within this function?” and we can’t tell that you used it properly. But we can say you at least tried to handle the error. You at least did something with it. You re-threw it. You send it somewhere.

You console logged it.

You did something.

You weren’t ignoring the error. And if you weren’t ignoring the error, we assumed, we’re pretty happy with that. We say, “Okay, you’re intelligent enough to realize that this could lead to problems if you just ignored the error.” And so, we’re able to handle that. So, I think it’s pretty cool. It uses, it’s the AST stuff. It goes through. It says, “Alright, did we ever use this identifier?” It looks for an identifier which just means basically a variable being used. And it matches it to the function arguments, the function parameters, and says, “Okay. You have a function parameter. It’s the first one, which is the standard callback pattern in Node.” If it’s ‘e’ or ‘error’ or several of these common ones, it will then check if it’s being used inside the function. It’s pretty cool.

That kind of reminds me of the theme with last week’s show. We talked a little bit about Rust and how it’s this language that encodes these best practices about systems programming into the language. So, instead of having to learn C and then learn, like you know the language C and never ever do this giant long list of things that you can do in C in a real program. It’s kind of the same with Node. So, the reason I complained about that error is we had some new Node programmers who ended up making that mistake just because they weren’t familiar with the environment. And it’s cool to see tooling encode knowledge because it’s a lot more scalable to spread that knowledge to people than with someone saying, “Hey. Don’t do that.”

Absolutely. Some of the other ones, I’ll just throw out there, that I thought were pretty cool, some of the other rules that enforce not throwing a literal. So, you could never throw a string if you enable this rule. And another one is ‘no restricted modules’. So, I don’t know how many of you out there use Underscore and Lodash. But I’ve noticed that a lot.

Probably more of you than you think.

[Laughs] Probably all of you do this. [Chuckles] And so, with ‘no restricted modules’ you could just say, “Alright, we’re banning Lodash,” or, “We’re banning Underscore.” Just pick one, because it’s so unnecessary to have two different versions of essentially a module that does almost the exact same thing in the project. And I think all these things enforce consistency and they help projects be more successful. There are tons of rules in there. It’s almost kind of annoying.

This is maybe one of the frustrations I have with ESLint. It’s that there’s so much interesting stuff in there, sometimes I don’t even know and I contribute to the project. I don’t even know all the things that it can do for me. And I’ll be frustrated about something and I’ll ask about it. And someone will like say, “Yeah, we’ve had a rule about that for a while.” I gave a talk about how frustrated I was with people throwing strings in JavaScript and how you need to write a custom rule to do that. Simultaneously, someone also had already contributed that rule to the project and I didn’t even know about it.

Wa-wa-wa.

So, I might have missed something. Is this like there’s a repository of rules? Is that what you’re saying?

Oh, well let me tell you how ESLint works internally. How about that?

Okay.

Not too deep, but a little bit deep. So, first I’ll start off by explaining a little bit about how, we talked about how that it uses a parser. It uses Espree which is basically a little bit like Esprima, basically the same thing as Esprima with some fancy new stuff. And what it’ll do is it’ll take your code, it’ll convert with Espree into a syntax tree, and it’ll pass that syntax tree to each of these different rule files. So, each rule is just a self-contained file. So, within the project itself you might have a rule that says ‘no console’. And we’ll pass the syntax tree into the ‘no console’ rule. The ‘no console’ rule will then look through that syntax tree for anyone calling console.log or anything like that. And we’ll report back those warnings. And then ESLint will then go to the next file, meaning the next rule file, pass the syntax tree into that file, and so on and so forth. So, each rule is a separate file. And so, it’s pretty straightforward how people can create new rules for the project.

In addition to ESLint itself having a huge list, may 50 or 100 rules itself that it enforces or allows people to turn on or off if they use ESLint, you can also ‘npm install’ a new rule. So, you can create an ESLint plugin very simply. And there’s a great ecosystem of rules for ESLint with thousands of downloads. There’s a whole bunch of rules specifically around JSX and React. There’s a very popular Angular plugin for ESLint that provides a whole bunch of additional rules for Angular. And so, there are tons of additional rules out there. So, it’s hard to keep an eye on the whole thing, right? If I want to do a rule for something, it’s very likely someone else created it somewhere else.

That’s interesting.

So, in some ways using ESLint feels like you get some of the comfort you get from a statically typed language with a compiler. I know by default it makes sure that you define stuff before you use it. So, you can’t just have implicit globals. It makes sure that you don’t have unused variables. And I know that I’ve had so many bugs in my JavaScript code from switching two letters around and just mistyping a variable or a function name or something. So, it feels great.

Yeah, so here’s one thing to throw a wrench in your happy feelings. ESLint 1.0 is coming out pretty soon. And one of the things that the project is doing is actually turning off all the rules by default.

So…

Oh, sweet.

Sounds terrible.

Happy feeling’s gone.

That’s so terrible.

Yeah. So, this is still being discussed. And obviously we’d love input from people. But I think the idea is that basically so many teams are having to… I just [inaudible] [laughs]. We have ways, right? So, there’s going to be, there’s this extends mechanism. So, if you want to just add all the default rules you just say ‘extends default’ or whatever the syntax would be. Or you can extend maybe some other Google style guide or whatever like that, that you choose. But the basic idea is that so many people have so many ways they want to customize things. And ESLint has sort of promised that we’re trying to be flexible. It’s trying to be this flexible thing. We’re not trying to enforce any one rule or another on you.

And there are a lot of rules that are turned on by default but I don’t really agree with. There’s this one called ‘no mixed requires’. And some people feel strongly that you shouldn’t have a require block like a variable declaration block of requires that also does other things. And I don’t care. I don’t understand why that’s turned on by default. And so, with this change basically all the rules are going to be off. You can turn them back on with just one configuration change. Or you can then customize it to your heart’s content. The only trick there that I’ve been dealing with is I don’t know what I need. And so, there are so many options that it will be a little bit tricky to steer people in the right direction if they’re not on top of everything.

What happened to the idea of reasonable defaults though? When I want a tool, I don’t want to have to go in and configure everything. I just want it to be like, “Here’s what 99% of sane, normal people need. And if you are doing something way awesome, then know that you need to change this to make your awesomesauce magic potion work.”

So, I can’t speak for the ESLint team to answer that, but I do have a question about that. Is it because there are now so many versions of JavaScript out there that it would be impossible to choose a default that applies to even a simple majority of developers? Like for example, ES5, ES6, now ES7, JSX, things like that?

I think in some ways, your guess is as good as mine. But there are so many competing ideas out there. And so, so many people are so frustrated with how the defaults are. We feel like it’s too opinionated. Or why didn’t you turn on this rule? And so, I think it’s okay to say, “You know what? Everything’s off by default. There’s sort of the ESLint recommended rule set. You can enable that if you’d like.” But it’s no longer going to be enabled by default. And you know, it’ll add a tiny bit of configuration, one extra line of configuration. But so many people are going to feel like they are not being pushed to go a direction they don’t want to go.

This also helps people for example when a new rule comes online. They automatically get that new rule and then all of a sudden it starts breaking their build, because they didn’t know to turn off a rule that was going to be enabled later. This has happened to us probably seven times at PayPal where we’ve had, everything is passing ESLint, ESLint does an upgrade, all of a sudden there’s a tweak to an existing rule. It gets a little stricter or there’s an additional rule that’s added and turned on by default. And all of a sudden, our build breaks. And we didn’t necessarily know that we were opting into every new rule that came down the line. So, there is a tradeoff there.

I think the new… it’s starting off with a blank slate. It won’t do nothing. Of course it’ll check for syntax errors. The most egregious things that will basically break the parser will still be checked.

But if you want to opt into any of the rulesets or anything like that, you’ll have to do that manually.

It sounds kind of like there are kids fighting in the back of the car like, “I want this rule on,” “I want this rule off.” And then Nicholas was like, “Don’t make me turn this car around, kids.”

And then he turned the car around and now there are no rules on by default.

No rules for anyone.

Are you happy? [Laughter]

You got what you wanted, kids.

Yeah, we’re not going to Disneyland.

That’s just so sad to me, because for the most part you’ve got 99% of JavaScript developers have no idea what they’re doing, because they’re part of the 99% of developers…

Who aren’t actually developers, right? Everybody plays with JavaScript.

Yeah.

And so, my thought is always on, how do you help the most people? Because the people that are super opinionated and doing crazy things, they can figure it out. Like, oh waah, it takes them two seconds to look at the documentation page. But for the other 99% of people, it’s like, “Oh man, this would have been so helpful if on day one I’d got this set up and then my code wouldn’t break all the time. I wouldn’t have all these errors.”

They can still do that. It’s one line of config saying, “Give me the defaults,” right?

But then they have to, it’s more that you have to know. It’s more that the person who’s getting into it for the first time, that’s where my problem is.

They already took the step at installing a linter.

Let me give you a thought.

[Chuckles] Yeah, they’ve already…

[Chuckles] It’s a pretty big deal.

My thought is that ESLint, I hope I don’t misrepresent Nicholas or the project at all. I feel like it’s a tool for professionals, right? This is a tool for experienced professionals that are trying to improve things. This is not necessarily a tool for a beginner to go and configure and install. It should work easily for a beginner. It should be easy to work there. But it’s really a tool for professionals.

And I think that treating our user base as professionals is not going to end up as a mistake. I don’t think we’re going to regret assuming some level of competence [chuckles] with the people that are using the tool. I know that it’s going to create issues. People are going to be concerned about things. But ultimately the basic linter with nothing turned on will at last check for syntax errors, really intense problems with the code. And it’ll be very easy to opt into one of many style guides. I think that will actually be really cool and help people feel more confident about the tool.

Just yesterday I was checking out some of the issues and I know people contribute to open source a lot and they don’t necessarily understand how much work it is to maintain these projects. And I

just do a couple of hours a week on ESLint related stuff, probably two hours a week. But I know Nicholas and some of the other contributors give a lot more time. And when people come in and… just recently there was an issue open and someone complained. “I thought this was supposed to be an un-opinionated framework. This is just as bad as Douglas Crockford’s JSLint tool because I don’t like there’s not an option to configure x, y, or z exactly the same way.”

I took that initially and I read that, I was so frustrated. I’m like, “You know what? People are donating hundreds of hours of time. They’re not jerks. They’re really, really nice people. They’re working really hard to create a tool that’s useful for everyone.” Eventually I realized, “Hey, this person’s not familiar with the project. They don’t understand.” But ultimately, the expectation for them is that, and one of the selling points of ESLint is that this is truly a flexible tool. It’s a tool to help your project be the way that you want your project to be. It’s not trying to help your project be the way that Nicholas wants your project to be, or Crockford wants your project to be. This is a project for you as a professional to configure the project in just the way that you want your team to have your project. I think it’s a great option.

Just anecdotally, the way that our team uses ESLint is there’s an option to just dump out the configuration into a JSON that includes every single rule. If I understand correctly, your config file can just list the rules that you want to manipulate.

Yes.

But there’s a way to just dump out all of the rules and then change those. And that’s what we do, just because we want to have control over it. And that’s why we use ESLint.

I think that’s pretty common. That’s what we do here at PayPal as well.

That leads me to a good question. So, I am like many people lazy and a terrible engineer. And I have a large JavaScript codebase with no linting. How do I get started? My experience has been with other projects that when you try to do this with an older codebase, it’s very hard to sift through the thousands of errors that you’re inevitably going to generate. How do you get through that, over the hump, and into the nice productive green beautiful grass fields?

That is a fantastic question. So, we do this, with this a lot. So, we often find little coves of code that were hiding out that hadn’t applied any lint rules, one of those caves of uncompliant code was in our unit testing. So, we weren’t testing one of our subfolders within our unit test directory. And there were hundreds of files in this folder. And when we discovered that it was missing, we were doing a look through our files. We found this whole subfolder that wasn’t getting linted. We said, “Oh, let’s turn on our standard lint rules for this subfolder.” And when we added it to the list of folders that were getting linted, I think that we found maybe several thousand errors, because within that project and within those files people were using double quotes and single quote. They were returning without curly braces around their if statements. And they were doing so many different things. And it was completely inconsistent.

So, I couldn’t turn on the rules one way or another, because it would ultimately not work either way. [Chuckles] So, here’s what we ended up doing and here’s what I’d recommend. Try to lint as much of your code as you can to a really high standard. But you can create a separate config file for a different part of your codebase that may be a little bit less strict. So, in our case we created an .eslintrc file. We put it at the base of that folder, which ESLint will then apply these new rules over the base rules. And what this list did, what the sub-list is, is it set everything from error mode which is in the configuration it’s 2 for error or 1 for warning. So, it warned on the things that were really bad that we actually cared about people fixing. We disabled rules that were, while on our normal we prefer that people had chosen one or the other, that we didn’t actually care enough to enforce it in this particular directory.

So, we disabled a whole bunch of rules. But all the rules that we cared about that we hoped people would fix we’d set to 1 as warn. So, when people updated those files, they ran their linter, well it didn’t break the build or stop them. They would see that there was a problem. And eventually we created stories in our backlog of things to do to eventually go up and clean up any of the things that were warning. And then once we fixed those warnings, we turned the rules on to error, so that if anyone went back and broke those rules again they’d be prevented from doing so.

So, you can do it in a step by step process. But the .eslintrc file, you can put that in. It’s just basically a JSON file with all your rules. You put that in the folder and you can relax rules or set things from instead of actually breaking your build, you can set them to just warn instead. And that seemed to work pretty well for us. Any other thoughts?

What are some of the errors I’m likely to hit first and how do I get around them?

[Chuckles] Get around them is an interesting way to put it.

Yeah. How do I make ESLint shut up? No, I’m just kidding. Like, do you have any examples from [inaudible]?

Yeah, so a lot of basic things. People have different ways of using quotes, semicolon usage, the way that they’re doing their if statements and return statements, triple equals versus double equals. These are things, famous stuff that have come around from JSLint. They’ve made it through JSHint. They’re still around. A lot of these old rules are still [inaudible]. And where you’re putting your curly braces, things like this. And so, a lot of these are default rules that a lot of linters are going to catch. And you will probably run into some problems on your codebase with those. And a lot of them though, and this is where a tool that ESLint doesn’t have right now which other projects are starting to adopt is this autofixer. So, it will just automatically update your styles to look in a certain way. I think that’s a really cool thing.

Wow.

Because that will fix a lot of problems. I think JSCS is working on something like that. I think JSHint maybe has something or there are some other projects that do that. So, you could feed in some kind of rules and it will try and, for example things like indentation, quotation marks, curly braces where you’re putting them, all that stuff. There are some tools out there that let you automatically fix that. But at some point, it’s like I don’t know if it’s worth the cost if you’re looking at hundreds of files that are old files. You’re not working on them actively. I usually like to update things when I’m working on them rather than just going through wholesale and changing old things, because I don’t want to break stuff.

Going forward, you have plugins I assume for all the different editors as well, right, like other projects do?

We had a problem on our team where some people were using WebStorm, some people were using vim. And all the people that were using WebStorm was automatically putting spaces in everything. And it just makes looking at the code review a pain in the butt. So, when we started using linting it helped with that sort of thing [chuckles].

Yeah, that’s [chuckles] Aimee that’s a great point. I think a lot of the tools we use, and especially if the team uses a lot of different tools, and most teams do, the tool themselves can have very different defaults. And so, one thing that I’ve seen is that projects of sufficient size may author, they may actually include for example with WebStorm I think it’s the .idea file.

Yeah.

You can include that in your project that may include certain rules about formatting. Or, maybe a .vimrc file. So, different files like that, config files that will allow people on different tools to end up with similar results. I think that could be helpful, because it is pretty annoying when people using different tools end up with different results. And then for them as well. Even if it’s caught with a linter, it still can be frustrating because it’s annoying to have to redo something that you’ve already built.

May tabs disappear one day.

I don’t think so.

As far as I can tell, tabs are… And doesn’t Go use tabs? Is that true?

I don’t know of anything that uses tabs except [inaudible].

Yes, and Gofmt forces it. And it’s freaking beautiful.

Yeah.

Go uses tabs?

Oh, no.

It forces you to use tabs. It’s not optional.

Well, at least they force you to.

[Chuckles] Yeah.

Go basically has a linter built into the language. Not the language per se, but I think it’s the Gofmt. A lot of these discussions just never come up.

And that’s beautiful.

Which is nice.

That’s beautiful. I hate tabs, but if it works and everyone does it and there’s no question of this editor or that editor, I’m all for it.

Hey, so I’ve got a question for the group here.

Hold on, it doesn’t work that way, sorry.

No. This how it works when you have me on your show?

So, is there one thing, is there one rule you would love to see in a linter or something that bugs you in code that you wish could be caught automatically?

Yes.

What rule are we missing?

[Chuckles] I have a dumb thing.

Jamison, you go first.

Dumb thing first. The most contentious technical discussions I’ve ever had have been over aligning equal signs.

Just so stupid.

What?

I am also so stupid.

So, if there was a rule that could say align all your equal signs or don’t align them, then I would turn that on and the discussion would end. And my life would be happier.

See, I don’t think the discussion ends though, because when I’ve been in that…

Clearly not.

It goes into a guerilla discussion.

The discussion…

There goes AJ, right?

To backchannels then.

Oh.

Then the rebellion starts.

Okay, can we do mine?

Alright, come on. What are the rules? Okay, that’s pretty cool, Jamison. I think it’s crazy but I bet we could get some [inaudible].

What about the next line commas. Is there a rule about that?

Next line commas? So, you’re talking about comma first?

The leading comma thing? Yeah.

Yeah, comma first.

I’m pretty sure we already do that. I’m pretty sure. I can double check for you.

Is this just like a throw down where you’re like, “Give me your best shot. We’ll see if we already do it.”

No, because…

You know what it is? It’s whatever I’m doing now, but I need it to be a rule in six months when I decide it’s really stupid. [Laughter]

So, that’s along the lines of my suggestion. So, here is mine. One of my biggest problems is that I

often find bugs after they go to customers. Could ESLint just tell me when I’m writing a bug while I’m writing it?

Yeah!

No, that actually is what ESLint does. ESLint will help you find your bugs. And if you’re having trouble with it helping you find your bugs, you should write a custom rule that will help you find that bug. That’s where I’ve found the most value with ESLint is for us it’s usually a crash in production. “Hey, we have a crash on our servers in production because we did something dumb. Okay, now let me go write, let me spend a day and a half and write an ESLint rule that will not let us do that anymore,” because we have millions of customers and they get mad when they can’t send money to their friends and family and everyone else. And so, it’s really important for us to prevent these bugs.

And so, ESLint lets us write our own rules so that… no one else cares about half the rules that I have in the system because we have our own big plugin with a bunch of PayPal specific rules. But they help us from making mistakes we’ve made before which is where I think it’s a huge benefit.

Aimee, what about you? Do you have any pet rules you’d like to see?

I was trying to think about that. You better skip me. I like Jamison’s. That’s a good one. [Chuckles]

[Inaudible], yeah. AJ, got anything?

No. I’m happy with rules existing and then being… the only, yeah, they need to exist and they need to be really easy so that when somebody’s got some thing I’ve never heard of before on their GitHub it’s got to be super easy for me to use it with vim or whatever so I can just contribute to the project and not worry about, “I put the semicolon in the wrong place for them.”

Ooh, ooh, I did just come up with one.

Oh, what is it?

I don’t know. This one would be pretty, this one might be… actually, it wouldn’t be that bad. When you have a list of variables, alphabetizing them. I’m one of those people.

[Laughs] What?

Ooh. I go by length order.

Is that for or pro, Aimee? Or against?

For alphabetizing, for.

We’ll do one where it has to be reverse alphabetical just for my services [chuckles].

Oh yeah. [Chuckles]

Oh, wouldn’t you just…?

Yeah, so what about…?

Oh, it’s just like when you have a list of 30 in a row and they’re just all over the place and alphabetizing that.

How about a maximum list [inaudible]

[Laughs] There you go, there you go. [Laughter]

No more than five variables [inaudible]

There’s your problem.

Yeah. Aimee, you can…

Or just the package.json. Like, oh my god. They drive me nuts.

You can make that rule, Aimee, and I’ll help you if you need help.

Awesome. Well, I love ESLint. Does anyone else have any more questions for me or I’ll just start blabbing on about things I like about it more?

I think that we’re probably running out of questions. This is probably a good time for us to start moving over to picks and wrap this bad boy up. Is there anything really important about ESLint that we didn’t cover Jamund, before we end the show?

Oh, I feel so sad that it’s coming to an end. But I understand.

These things must happen. I would say this. If you have something you want to be linted and you have some ideas about… I guess if you have a rule that you want, I’ll always npm first. You can type ESLint plugin on the npm search and there’s tons of plugins for Happy, for React, for all sorts of various things that you might care about. And yeah, and the second thing I would say is we love contributions. We love people suggesting new rule ideas. Or if they want help creating rules that are specific for their team, we have a Gitter chat. We have obviously our GitHub where you can post issues. And it’s a pretty cool group of people that are contributing to the project. And we’d certainly love your opinions and ideas. But try to be nice if possible, because we’re all tired.

Awesome. Well, let’s move onto picks. AJ, would you like to go first?

Yeah, I’ll go. Alright, so first I’m going to pick again Mozilla. I really like them. And they had an article that solved one of my problems. So, I was complaining on a previous episode about UTF8 and binary conversion. And they actually have some tools in their wiki that has sample code that will correctly figure out, even if it’s an N-byte Unicode character or UTF8 character it’ll sort it all out and give it to you in a typed array. And that made me happy.

Alright. Aimee, do you want to go next?

Sure. I have two again this week. The first one is a video that I watched a while back. And it’s a guy who, he created a game in JavaScript. And it’s kind of just about how he thinks of the direction we’re going with user interfaces, that they’re more and more like game development. So, he just talks about some patterns in there that you’d want to use that he learned from building this game that you’d want to use in UIs.

And then my second pick, I think I picked the Headspace app a while ago. And this was another one from that talk at ng-conf on meditation and mindfulness. But I started reading the book. It’s called ‘Search Inside Yourself’ which just sounds like a really, I don’t know, lovey-dovey title and I’m not into that kind of stuff. But the book is pretty good. It’s by an engineer at Google. So, I like the fact that it’s written by an engineer. So, I knew that the title wasn’t going to be too lovey-dovey.

[Chuckles] Anyways, those are my two picks this week.

Fantastic. Dave, how about you?

Okay. A couple of picks for you today. And I think this, my first one, has been mentioned on the show before. But it’s a really fun YouTube show called Good Mythical Morning. I think some of the panelists are watchers of the show occasionally. Good wholesome fun, good funny guys, Rhett and Link. You’ve probably heard of them from other YouTube ventures and I quite enjoy them. Good family watching too, if you have kids. The kids laugh. I laugh. And it’s just fun to laugh together.

My second pick is actually my home city, Salt Lake City. If you are looking for a cool place to visit, I was just looking around this weekend and realizing how beautiful it is here and how fun it is. I got to go on a really long bike ride this week around the valley. And it’s just glorious. So, I’m going to pick the entire city of Salt Lake City. And that’s all I have for you.

Awesome. I think that covers everybody important on the panel.

What? No.

I’m important.

Wait. I forgot, I meant the less important ones on the panel.

Oh. Thank you.

And now for the most important picks.

Thank you.

Jamison, how about you?

One is a YouTube video of B.B. King playing in Sing Sing Prison in the 70s. He was a famous blues guitarist that passed away recently and so I’ve been watching a ton of his stuff lately. And it is amazing. He just tears the roof off the place. It’s so good.

The other thing is something called json-server. It is basically a fancy REST API wrapped around a static JSON file. And it’s perfect if you’re just building some kind of UI demo that you need an API to back up with. And you can just ‘npm install’ it and then it’ll let you post stuff and put it in a JSON file. And I don’t know. It just takes care of things magically for you. I found a dearth of good APIs for demos. So, this is a really way to make your own. Those are my picks.

Awesome. Alright, I’ll go next. I have two picks. The first one is for anybody out there who happens to have a significant other who loves things like Jane Austen but you yourself happen not to. If so, I have a movie for you definitely that you… I hardly believe that you will enjoy and will win points with your significant other. It’s called Austenland.

That’s a good one.

Yeah. Amazingly hilarious movie. If you haven’t seen it, I highly recommend it. It’s just so funny. I myself happen to have very little interest in anything Jane Austen. And when my wife rented this movie for Valentine’s Day I was vehemently against it and ended up laughing and enjoying that movie. Recently we watched it, watched it several times. Love the movie. So, that’s my pick, is Austenland. Hilarious movie.

And then I have another pick. I just saw the preview for the Supergirl series that’s going to go on CBS I believe in the fall. And I’m picking it out of hope that it’s good, because I’m worried that it won’t be good. And I would like it for it to be good. So, I’m picking it in hopes that it will be good.

And that’s my last pick. Jamund, you’re up.

Yeah, so lately I’ve been reading this book about science. Actually got it 10 years ago and I’ve been reading it for 10 years, because I’m a really slow reader. But it’s called ‘A Short History of Nearly Everything’ by Bill Bryson. It’s a super cool book. It talks about how all the scientists know all the things that they know. And it’s really cool.

The second pick that I’ll throw out there, ‘The Book of Mormon’, the actual book version. It’s great.

It’s totally inspiring. I love it. That’s it for me.

Fantastic. Well, thanks a bunch for being on the show, Jamund. We really appreciate it. It was a great episode. And we appreciate you coming on to talk about ESLint. And thanks everybody else.

And thanks to the audience for tuning in. We’ll see you next week.

See ya!

Bye.

Later.

Yeah.