Transcript from the "ESLint Setup" Lesson
>> Brian Holt: So down here we're gonna say npm install -D eslint eslint-config-prettier like that. This is going to install two different things for us. It's gonna obviously eslint, which is a code linter. Let's talk about what the difference between prettier and eslint now. Because people kind of confuse the two and understandably so, there's overlap.
[00:00:31] Prettier is purely concerned with is there a space here? Is there return here? How does this file star, it's very mechanical, right? It's very much, how is this formatted, but it doesn't care about what the code actually does, right? So it doesn't look like does this variable exist?
[00:01:09] Does that make sense? So you can have eslint check some of the mechanical stuff. But it doesn't have the power that prettier does for that kind of stuff. So that's why we're going to install the prettier config, to basically say hey eslint. That stuff that you sometimes worry about like spacing, don't worry about it because prettier has it, right?
[00:01:27] So install both of those.
>> Brian Holt: Okay, and now we have both of these. Eslint-config prettier, eslint, and now we're going to go create A eslint-rc as well. So make a new file, save it. And call this .eslint-c.Json.
>> Brian Holt: They require you give it the extension, whereas .prettierrc does not.
>> Brian Holt: And yes, I use a period. Did you have a question?
>> Speaker 2: When I ran the command in the terminal, it created a new file called package walk, is that JSON?
>> Brian Holt: Yep, it should do that. All right, so let's let's just address that briefly. If I go back over here, it created a new file here called package Lock. So package lock is a lock file. [LAUGH] So what it actually does is when you deploy your code to production, it's actually locked down the versions.
[00:02:58] If you look at this you can see that it has integrity checks, and like where to download it from and what version it's on and stuff like that. And you want it to have this, because now I can install exactly the correct versions in productions. So, what I'm running in my computer, is exactly what's running on production.
[00:03:18] So, the way that you do that when you're running in production, don't do this on your local computer, but if I do it npm, oops, npm ci. It'll actually use the package lock and sort of package of JSON to install exactly the correct version, right? Whereas if you do NPM install see if I got a package of JSON here.
[00:03:39] Let's say you know next week they release 1.17.1, right? If my file looks like this. It'll actually install at 1.17.1. Reason being it's because that's a patch version, so it should be compatible, right? Does that make sense? Whereas if I do MPMCI, it'll actually install exactly the versions I was using.
[00:04:00] So it'll still install MPM 1.17.0. Does that answer your question?
>> Speaker 2: Yeah. Thank you.
>> Brian Holt: Cool. Yep, it's the same thing as a Yarn log file. The packaged log and Yarn log accomplish, as far as I know, exactly the same thing.