Published: Oct. 23, 2018, 10 a.m.
Panel:\xa0
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!\xa0Show Topics:0:05 \u2013
Advertisement: KENDO UI 0:37 \u2013 Hello! The panel is...(Chuck introduces everyone).1:04 \u2013 Nicholas who are you?1:17 \u2013 Nicholas: Yeah it\u2019s been about 5 years and then you invited me again, but I couldn\u2019t come on to talk about ESLint back then. That\u2019s 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 \u2013 Chuck: What is it?2:04 \u2013 It\u2019s 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\u2019ve created it. It can help with bugs and enforcing style guides and other things.2:53 \u2013 Where did it come from?2:57 \u2013 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\u2019t 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\u2019s not a good way to be checking code for problems. I wanted to find a better way.6:04 \u2013 Why did you choose to create a product vs. using other options out there?6:15 \u2013 Guest: Both of those weren\u2019t 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\u2019s what we need. Why would I build something new? I didn\u2019t see anything on GitHub and didn\u2019t see the status of that. I wanted to see what the plan was, and they weren\u2019t 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 \u2013 My history was only back when it was customizable.8:13 \u2013 Aimee: It\u2019s interesting to see that they are basing it on regular expressions.8:32 \u2013 Guest: Interesting thing at Box was that there was...I am not sure but one of the engineers at Box wrote...9:03 \u2013 Aimee: I was going to ask in your opinion what do you think ES Lint is the standard now?9:16 \u2013 Guest: How easy it is to plug things in. That was always my goal because I wanted the tool not to be boxed in \u2013 in anyway.The guest continues to talk about how pluggable ESLint is and the other features of this tool.13:41 \u2013 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 \u2013 Guest: How do you start introducing new things to a team that is running at full capacity? That is something that I\u2019ve 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\u2019t a god way to share that information within a team in a non-confrontational way. It\u2019s better to get angry at a tool rather than a person.Guest goes into what this can teach people.18:07 \u2013 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 \u2013 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\u2019t 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\u2019t feel like when they were committing to a file why should I be...The idea with the different scenario levels you don\u2019t\u2019 want to turn off rules so people don\u2019t 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 \u2013 it doesn\u2019t 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 \u2013 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 \u2013 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 \u2013 Guest mentions his second favorite rule, here!28:24 \u2013 Guest mentions his third favorite rule, here!29:03 \u2013 Guest mentions the rule that makes him giggle a lot, here!30:07 \u2013
Advertisement \u2013 Sentry! 31:22 \u2013 What is your take on running Fix? Does it make sense to run Fix?32:00 \u2013 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\u2019t 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\u2019t want...People are probably wondering: Why doesn\u2019t ESLint doesn\u2019t 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 \u2013 Do you run Premier?35:20 \u2013 Guest: No I don\u2019t. I don\u2019t have anything against
Premier but I think
Prettier uses a very interesting space.37:50 \u2013 Chuck: What is next for ESLint and what is next for you?37:55 \u2013 Guest: Well, to be honest I am not sure what is next for ESLint. I haven\u2019t 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\u2019s 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.
