Sessions is temporarily moving to YouTube, check out all our new videos here.

Make Linting Great Again

Andrey Okonetchnikov speaking at viennaJS in June, 2017
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

Watch how you can create fewer bugs and make the code more readable with linting tools. But does linting really make code reviews faster? If so, how?


Hi everyone. I'm Andrey. You might know me from React Vienna. I'm one of the organisers, and I have stickers with me, so if you want, have some stickers. Just go ahead and grab some. Today is... Yeah, what the lint, right? So, I think all of you are familiar, but I have this reference from Wikipedia, which isn't really helpful, but still, in short it's a static analysis tool. Interesting, but today we use linters not just to find bugs, but also to enforce code style on a project. The next question is why should we even lint or code, right? Because, you don't need to uglify your source code if it's already ugly. Just like, cool! But seriously, using linting tools helps us to create fewer bugs, make the code more readable, which is less time for code reviews in a team, and it's also faster on development cycle. We'll get to this in a minute. I found this interesting research that says, "On average, software developers spend "50% of their time finding and fixing bugs. "This inefficiency is estimated to cost the global economy "312 billion per year," which is a huge amount of money, so if you don't lint, you're literally just burning money. I thought a little bit about this quote, and I came to this one, just by me. "On average, software developers spend 30% of their time "discussing code style." Yeah, it's probably more, I just made up this number, so this is like, you know. Probably everybody knows. The next question is how to lint, right? So, now you probably are all encouraged to, convinced to do so. Actually, so many tools, not just for code linting, even for text linting. For JavaScript or ECMAScript, ESLint is amazing tool. Or with JSHint, still scss-lint, or even JSONLint. Stylelint for your CSS files that can be used with Less or Sass, by weight But, the main question is, is it really faster to lint and always toying around it? I just want to take a short look at our standard developer flow, as I imagine it. So, we write our very nice codes, right? Then, we create a PR, and submit it, for example on GitHub, for a code review. Just to point out that the build is suddenly failing, right? Ugh, it broke everything. So, we go to GitHub again and see that, Travis CI build is failing, so it's probably a bad thing happened. So, we go to Travis CI's like, yeah, missing semicolon. At that moment, I usually look like this, like ugh. So, we go back to the page to add the semicolon. We push it again, it's all good now. So, it's next spacing on tips. - [Man From Audience] Don't have any validation or codes, and just push everything like the testing, we don't have to fuse it. - Right, I already said if you, like if your code is off, if your code is ugly, you don't have to use ugly file tool, which is basically, we're saying yeah, you don't have to. If you don't have CI, your code will never fail, or if you don't have tasks we can fail, but, yeah, I assume we, like everyone, is doing good things. So, the question of life is like, why is it so hard, right? So, raise your hands who have been in familiar situations. Right, so, okay, I was expecting more, like hundred percent. Okay, we got 90, so the rest 10% probably don't lint or don't use CI That made me think, how many projects out there suffering from this? I went to GitHub to the most popular projects, which one is like Webpack for example. It has many, many comments. So, this is just one day, yeah? So, if you start looking at it, it's like first one, and then this one, and then this one is like, wow, and I didn't even scroll yet. Because if you start scrolling, it goes like that all the time. Then, I searched the global GitHub search, like fixing lint and fixing indentation, and I got like 500 commit results as fixing lint, and almost 3,000,000 of fixing indentation. Which is like, wow. "I wish I could lint before committing the changes to the repository," right, at this moment? Yeah, but the problem is, it's kind of hard, so you need to set up a pre-commit hook and git and it's like, I don't know, it's not obvious, yeah? So even, like smart people out there saying, I don't know how to add a githook in GitHub repo. Deal with it. So yeah, git hooks are hard to set up, hard to manage, and hard, this is the most important thing for me, hard to share across a team. Because, even if you figure out how to create a hook and add it to your repository, it will not be automatically shared across your team. So, then the guy sitting next to you or the girl sitting next to you will probably do the same mistakes as you and this is not gonna help the whole commit history. The good news are, there's a package for that, an NPM, so you can just go to NPM or use yarn, and instal husky. The thing is, husky will instal not just pre-commit hook, but all git hooks, and you can reference them in your package adjacent like this, or you just add a new script. It says precommit, and you say eslint dot, Which basically links everything in the whole project. This lint is smart enough just to lint only, Javascript files are... But there's an issue, if you start doing good on the bigger legacy project, you might face something like this, like 6,284 errors in just one run, and this run took me a couple of minutes to see this result, so if you try to run this in pre-commit hook every time, you will be basically thrown out of the flow for a couple of minutes, and this is not good, believe me, you don't want to wait for just type your commit message for a couple of minutes. So, let's add some things, so we fixed like three first problems of these git hooks with husky, but still, things are slow and they display irrelevant results because you purposely changed just one file, but you've got linting curves for the whole code base. This is where you meet lint-staged. This is what tool I created because of this programme, and I maintain right now, and it's also easy to set up. It's basically npm instal as a dev dependency lint-staged or yarn ad dev lint staged. Instead of running eslint here in the speaker machine, you just run lint-staged, and the second thing you have to add is lint-staged config, which it consists of scopes and commands you want to run for these files, type of files. So, in this case, we want to run eslint on every Javascript file we're about to commit. This is how it works. So, the next time we have just one file added onto index of commit, and it's missing semicolons, you see, and then I, to commit. It runs as pre-commit, which is running lint. So, it says, okay, you have missed semicolon and verb, couple of other errors we didn't know about. But still, this is much faster and this is only errors that are related to your changes, basically. So yeah, git hooks are awesome, if you cook it correctly. Can I just finish, because it's just one minute, and... - Yeah, yeah. Thank you. But there is more, because now you can actually automatically fix your linting errors. So, it's also easy that you just write eslint --fix and then git add, and this git add thing probably will go away, and the next version. I hope so, so don't copy paste as right now, wait for it. Even there, there's this amazing tool called Preacher, which re-formats your code automatically, and this is how easy it is to set up this pre-commit hook, and this is how it works like. So, imagine you have this very, very badly written Javascript code, and this J6 example. Now, I'm trying to commit it, and it's done, but then you show it, it's nice again, you know? So, you don't have to even think about it, so it's just done automatically, and because Preacher has very, very few conflict options, and you share basically across the team, everyone writes automatically same code styles, so you don't have any discussions about, should we add a space here or not? So, you're not wasting your time on these stupid things. This is the reaction of, then everyone, when linstage was introduced, this preacher was introduced to create-react-hub, so we're using it internally, and we're waiting for one actually major issue, and trying to resolve for months already, but I think there will be a solution for that. So, as soon as the solution is found, they will be using it for any create-react-app in basically for users as well. Today, I discovered that it's also being used at Babel, so the whole Babel code base is being linted or formatted with preacher and this help of lint-staged, which is cool because we're like big communities using it, so it's for use, like it's production tested. So yeah, if you remember this one, don't do this, just grab this one, this package, and please, please, please solve real problems. Thank you.