JSJ 336: “The Origin of ESLint” with Nicholas Zakas

Panel:

• Aimee Knight
• Charles Max Wood (DevChat TV)
• Christopher Ferdinandi (Boston)
• Cory House (Kansas City)
• Joe Eames

Special Guests: Nicholas Zakas In this episode, the panel talks with Nicholas Zakas who writes on his site, Human Who Codes. He is the creator of ESLint, also the author of several books, and he blogs, too. He was employed through Box and today he talks about ESLint in full detail! Check it out! Show Topics:0:05 – Advertisement: KENDO UI 0:37 – Hello! The panel is...(Chuck introduces everyone).1:04 – Nicholas who are you?1:17 – Nicholas: Yeah it’s been about 5 years and then you invited me again, but I couldn’t come on to talk about ESLint back then. That’s probably what people know me most for at this point. I created ESLint and I kicked that off and now a great team of people is maintaining it.1:58 – Chuck: What is it?2:04 – It’s a Linter for JavaScript. It falls into the same category as JSLint. The purpose of ESLint is to help you find problems with your code. It has grown quite a bit since I’ve created it. It can help with bugs and enforcing style guides and other things.2:53 – Where did it come from?2:57 – Guest: The idea popped into my head when I worked at Pop. One of my teammates was working on a bug and at that time we were using...Nothing was working and after investigating someone had written a JavaScript code that was using a native code to make an Ajax request. It wasn’t the best practice for the company at the time. For whatever reason the person was unaware of that. When using that native XML...there was a little bit of trickiness to it because it was a wrapper around the...We used a library to work around those situations and add a line (a Linter) for all JavaScript files. It was a text file and when you tried to render code through the process it would run and run the normal expression and it would fail if any of the...matched.I am not comfortable using normal expressions to write code for this. You could be matching in side of a string and it’s not a good way to be checking code for problems. I wanted to find a better way.6:04 – Why did you choose to create a product vs. using other options out there?6:15 – Guest: Both of those weren’t around. JSHint was pretty much the defector tool that everyone was using. My first thought was if JSHint could help with this problem?I went back to look at JSHint and I saw that on their roadmap you could create your own rules, and I thought that’s what we need. Why would I build something new? I didn’t see anything on GitHub and didn’t see the status of that. I wanted to see what the plan was, and they weren’t going to get to it. I said that I really needed this tool and I thought it would be helpful to others, too.8:04 – My history was only back when it was customizable.8:13 – Aimee: It’s interesting to see that they are basing it on regular expressions.8:32 – Guest: Interesting thing at Box was that there was...I am not sure but one of the engineers at Box wrote...9:03 – Aimee: I was going to ask in your opinion what do you think ES Lint is the standard now?9:16 – Guest: How easy it is to plug things in. That was always my goal because I wanted the tool not to be boxed in – in anyway.The guest continues to talk about how pluggable ESLint is and the other features of this tool.13:41 – One thing I like about ESLint is that it can be an educational tool for a team. Did you see that being an educational tool?14:24 – Guest: How do you start introducing new things to a team that is running at full capacity? That is something that I’ve wondered throughout my career. As a result of that, I found that a new team there were some problems I the code base that were really hard to get resolved, because when one person recognizes it there isn’t a god way to share that information within a team in a non-confrontational way. It’s better to get angry at a tool rather than a person.Guest goes into what this can teach people.18:07 – Panelist: I am not surprised. Is there a best practice to get a team to start with ESLint?Do you get the whole team in a room and show them the options or take the best guess and turn it on?18:34 – Guest: The thing I recommend is that first and foremost get ESLint in your system with zero rules on. It starts that mindset into your development process. We can do something to automatically check...Get Syntax checking and you will se improvements on the number of bugs that are getting out of production. I recommend using the default the ESLint configuration. This has all of the things that we have found that are most likely errors and runtime errors vs. syntax errors. You can go through with those and sometimes it is easier to run that check with...Using those ESLint rules will clean up a lot of problems that you didn’t know you had with your code. There are too many problems with those rules. I recommend instead of turning them off then put the severity to warning and not error. That is something we started with in the beginning. We turned on as many rules as we could and it drove people crazy. They didn’t feel like when they were committing to a file why should I be...The idea with the different scenario levels you don’t’ want to turn off rules so people don’t know there is a problem. There can be a rule on so people will know that there is a problem, but...Doing that alone will give you a lot of benefit in using ESLint. How do you decide as a team on the rules that are maybe not for finding errors but for stylistic in error? Do we use four spaces, semi-colons, etc. To figure that out I am a big component on finding a pre-existing style guide and adapting it. Get everyone to agree.There is no right or wrong when it comes to stylistic preferences. It really is just getting everyone to do the same thing. I think it was Crawford that said: Whether you drive on the right side of the left side of the road – it doesn’t matter as long as everyone is dong the same thing. I agree with that and it applies to style guides. It can get heated but for the best thing for the team is stick with a guide and work together.24:36 – Aimee: I can go through the options to pick one of the style guides out there and then it will automatically create my configuration for me is helpful. Question: If you had to pick 2 or 3 rules that you are super helpful what would they be?25:30 – Guest: To touch briefly on indentation. Whether you like four spaces or whether you are wild and like tabs, I think the indent rule is very helpful. Just for wiping out and eliminating that discussion through your team. Have your editor setup however they want but on the pre-hook...But my favorite rules I tend to lean towards the ones that saved me.The Guest goes through his favorite rules with ESLint. Check it out!26:51 – Guest mentions his second favorite rule, here!28:24 – Guest mentions his third favorite rule, here!29:03 – Guest mentions the rule that makes him giggle a lot, here!30:07 – Advertisement – Sentry! 31:22 – What is your take on running Fix? Does it make sense to run Fix?32:00 – Guest: It depends and the idea behind Fix is the idea of doing a one time (at the start) fix everything that it can find wrong b/c I don’t want to do it by hand. It morphed into a more of a tool that people are using all the time. I too have mixed feelings about it. I think the greatest value you get out of Fix is that when you first install it or when you enable a new rule. I think in those situations you get a lot of value out of Fix. I think that when people were getting aggressive with their code styles it took us down a path where we...As a pre-commit hook it could be to fix things and part of the built system you wouldn’t want...People are probably wondering: Why doesn’t ESLint doesn’t fix all the time?It can be a team decision: do you want to run Fix at the point that the developer is writing the code, do you want to use Fix as running it as a build when you are bundling? It really seems more of a personal preference. I am on the fence about it. Even though I am leaning more towards...35:16 – Do you run Premier?35:20 – Guest: No I don’t. I don’t have anything against Premier but I think Prettier uses a very interesting space.37:50 – Chuck: What is next for ESLint and what is next for you?37:55 – Guest: Well, to be honest I am not sure what is next for ESLint. I haven’t been involved with keeping it maintained for the last few years. I do help out with feedback with decisions. But in general the ESLint the direction is that let’s add tings that help people avoid language hazards and make sure that ESLint is still pluggable. Lastly, that we will be there to help people and the community. There is this virtuosic cycle and tools like Babble and then tools like ESLint introducing rules adapting new rules and featur

Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.