Transcript from the "Configuring ESLint" Lesson
[00:00:00]
>> The next thing we're gonna add to this small library is linting, so this is static analysis to make sure that we're using good patterns and enforcing code style. So we already have es lint installed as a dev dependency, but you could install that now if you have not done so already and let me close out all these files.
[00:00:24] So, what we need is an es lint setup to who here is configured, who in the class has configured es lint before for a project, couple people, but half the class. So those of you who haven't done this yet yes lint has some great functionality out of the box.
[00:00:46] But particularly if you're working with react or if you're working with TypeScript, or if you're working with view, you need to add a bunch of plugins and it's not just simply just install this one package I don't advise that you use this specific code in your app. But what I do want you to see is instead of relying on an if else, combined with this type guard that returns a Boolean, now where we're defining a different type, a different kind of type guard where and in the notes of the way I would like you to answer these questions.
[00:01:18] And I'll go through just as I've written down there, so we want to check syntax and find problems. I don't wanna enforce code style because I typically rely on something like prettier for that. I feel like prettier is a good, nice, dedicated tool that does a great job at solving that problem and that problem alone.
[00:01:40] So I want es lint out of get out of the business of semi colons and tabs and things like that let prettier handle that but that's my personal opinion, all right. What types of modules does your project use, well, really none of these We're certainly writing TypeScript, so it doesn't seem like JavaScript, right?
[00:01:59] And we're not writing common jass although we're compiling, that's our output, but it's not we're not writing. So none of these and which framework does your project use, so we've got react and view but I would say none of these. Do we use TypeScript surprised the answer's yes, try not to be shocked and we'll say we're using that, so we're using node, not a browser.
[00:02:29] And I would like my config file to be in JSON And then this is not ideal, I wish it had better support for yarn. But it's gonna install them via NPM and we're gonna have to like, do a little work around here, it's not a big deal, but it would be great if it could handle yard as well.
[00:02:52] So I'm gonna say yes to this question and here's npm doing its thing. So if I had answered no, I would have had to copy this line and make the appropriate modification to my package JSON, and then run yarn. I'm kind of letting it do its thing here, because I want the package JSON handled for me automatically.
[00:03:18] And I'm just gonna rerun yarn, so it updates its lock file. So let's check our package JSON, we see these two things have been added which is great, TypeScript ESLint seems like TypeScript support for ESLint, right? Unfortunately, we have this package lock thing, I'm just going to delete this cuz having to lock files is a bad idea.
[00:03:45] They use totally different methods for resolving the right exact dependency version. So even if you do have both of those now NPM lock file and yarn lock file, they won't agree with each other. Especially for a big project, they will definitely not agree with each other, so you don't want to have those two things.
[00:04:08] They are not equal to each other, all right now I just need to run yarn. So that this lock file thing is updated, it should turn green in a moment once it's done A little bit of a workaround, but not certainly not the worst tech all right, so now we have ESLint installed, so let's look at our EsLintRC.json file.
[00:04:39] So this is sort of set up in a basic way, we're using ECMA version 12 which is this, yes 2021, that seems a little bit too modern for my taste. It's like next year's JavaScript, I'm going to go with 2018 because that's the same. That gives us async and await what the hell I'll leave it modern and we'll see if we run into problems.
[00:05:09] But you certainly something you wanna think about, especially as we start, I don't think we're touching on any really modern features here. I probably will make a difference in our case, but give this some consideration, right? Because we've got multiple places where we're stating the version of things that we're expecting to use, right, we're saying I want to develop on node 12.
[00:05:32] You could have had an engines object in your package JSON that says I support node greater than 10. And then your TS config, potentially you could have this lib thing, this lib option where you'd say, I wanna support es 2018. But don't like bust me if I try to use as 2019, so you have many places where you're stating the language level that you wanna allow.
[00:06:01] You just got to make sure that you're not permitting things you don't intend to permit. We talk about this, so yes, lint recommended that's a very basic set of rules. And then this rule TypeScript ESLint, recommended is some TypeScript specific basics that are very cheap to evaluate. There is an additional one that I wanna add which is recommended requiring Type checking, I hope I spelled that right, let me make sure.
[00:06:45] Looks right, so what I'm doing here is by default, we're sort of lending our typescript in a way that doesn't require that we make sure everything lines up with everything else. That's what you get out of the box and I'm opting into additional linting rules that require more type information.
[00:07:05] They're more expensive and I'm opting in and for a small library, it totally makes sense to do this. We're gonna add some rules here, really I'm gonna enable one prefer const, all right. And this I know their opinions about constant let me give you my reasoning for why I prefer const.
[00:07:34] TypeScript will make the safest possible assumption sorry the strictest possible assumption that it can make safely. So if you say const x equals Mike, it will say well, you can never reassign this, this is an immutable value type. So it's gonna say, the type of x is actually Mike, it's not just an arbitrary string, it's this string literal.
[00:08:02] It's exactly the string Mike no other strings allowed, so const behaves differently in terms of type inference. And it's also more convenient when working with type cards because once you give const of value. You can do things like make assertions on it and use type guards and narrow it down and the compiler understands that you can't switch things around, like once you validated a const.
[00:08:34] If you're unable to change, it can assume that you're getting more and more specific and more focused down. If that were a let variable declaration, well other code that you write, like if you pass this value into other functions or like there's the potential to mutate it, and so on.
[00:08:56] There are fewer assumptions that can be made, because more is possible with a lead. So that's why I like using const whenever possible with TypeScript, so I'm going to turn that on. And I'll say, look, if I'm in a case where it's possible to use const, let's use it and I will turn off some things that are enabled by default because our compiler is handling it for us.
[00:09:25] So no one used veirs is off as is no unused params let the compiler do that job, I don't need yes lint to also be doing that job. It's literally gonna give me errors where I already have errors and I only need one, okay. This next step is going to feel slightly convoluted, but I promise, there is method to my madness, we're going to create another tsconfig file.
[00:10:03] And it's called tsconfigEs Lint.JSON, here's why, I the way I'm setting this library up the tests and the code being tested, are very separate. Like just is allowed for use in the tests only, not in the source folder, we have to have that separation. But es lint wants one TypeScript configuration that includes all of the code that I want lint it so I have to give it one that will make it happy.
[00:10:37] This is a Ts config for ESLint specifically. Now I wanna make sure that I'm not taking on additional maintenance burden here. So I'm gonna say just extend from my normal tsconfig and the only thing that I wanna say is allowed Is, we're gonna say types jest is allowed and I can include both my source folder.
[00:11:15] And tests, so the benefit we get here is, I can kinda forget about this file now cuz it's inheriting a lot from the, the real test config let's call it the real one. Going back to my es lint config here real quick, which is on the bottom, one little thing I have to add I have to tell.
[00:11:45] Yes, lint that it's to use this Ts config. The only reason I need this here it's because of the rules I opted into on line 9. We want those rules that use type checking information and we have to tell es lint what it is to use when considering.
[00:12:13] Like, which file defines the project to be limited and in this case it's that specialty is configured. All right now, the code for our tests which we have yet to create but I'll tell you where they're going to end up. You can say files and here we can say there'll be in tests.starts, so all the TypeScript folder, TypeScript files in tests and then end jest just true.
[00:13:02] And we can also say no true, which would be useful if we were like reading fixture data from a file or something, then we can use the FS module. No harm allowing node stuff to happen in our test suite, make sure you look at this path carefully tests All right, the time has come for us to see if this works, so the easiest way I know of to see if my linter works is to do something that my linter is going to bark at me about.
[00:13:41] And in this case, let's take advantage of the throw away enabled, let's see if we get that. There we go, so prefer const, this is evidence that yes, lint is working and it's is using a rule that I had to turn on. So I believe that our linter is working at this point and let's actually try to run it, yarn lint.
[00:14:18] One problem And that's the problem we hoped we'd find, linting works I'm gonna change it back real quick