Transcript from the "Standard.js with React" Lesson
>> Brian: Now Standard's not being super useful for us, so let's go ahead and go fix Standard real quick.
>> Brian: So first thing we wanna do is we wanna be able to test, not only Standard but Standard React rules. And the reason for that being, it's like we wanna additional enforcement of make sure you're put setting prop types which we'll talk about in here in a second, but there's other best practices for React that we want to enforce.
[00:00:28] So the first we wanna do is we wanna create a new file and it's called dot, again the dot being important, eslintrc.json.
>> Brian: The reason why .json and this is gonna go on just the home directory of your, let's say the home directory of the,
>> Brian: The root directory of your project, I have mine in Bundler here complete intro to React, okay.
[00:01:03] You can also do this with YAML I think, if anyone's into that I don't know why you would be, but if you are, go ahead. I'm going to do mine in Json, okay, and then it's gonna be extends. It's going to be Standard and Standard, sorry lower case, standard-react.
[00:01:32] And this is basically saying go out and find these ES Lint rules and use this as my ES Lint rules, okay. And so now instead of interacting with Standard directly we're actually gonna interact with ES Lint, which it's going to load all of our standard rules and the only reason to do that like I said Standard is not configurable in any way like Standard is exactly what Standard is, it will not let you input anything else.
[00:01:56] So if you want to get around that they said well if you want to make like this config than just drop down into ES Lint, load our rules and then do whatever you want. That makes sense to me, some people find that really annoying but I'm okay with it.
[00:02:10] Okay, so now we have ESLint set up and now we actually want instead of having to look every single time and like run mpm, run Lint a bunch of different times, why don't we just have Webpack run it every single time that we save, right? That would actually be pretty cool, cuz every time there's a console they could see everything that we were doing wrong.
[00:02:28] So let's do that, let's go to our webpack.config.js.
>> Brian: Okay, here we're gonna do preLoaders. Now why preloaders? Because we actually, we don't wanna run standard on bundle, right? We don't wanna run it on the code after it's run through Babel, we actually wanna run it before, right?
[00:02:59] We wanna make sure our source code is correct, right? And then we don't actually care what the bundle looks like once we are sure that our code looks correct.
>> Brian: Okay, so we're gonna do another test, it's gonna be the exact same one, in fact you can copy and paste this one if it works better for you.
>> Brian: So I just need to be inside of an object.
>> Brian: Okay, loader, eslint-loader.
>> Brian: And, the one thing that we wanna exclude is we don't actually wanna Lint our modules cuz that makes exactly zero sense. So we're gonna give another regular expression that if anything matches node modules just ignore that's because we don't care if it's in node modules.
[00:04:05] Cuz otherwise it's gonna let Lint react for you which if react has Lint errors you don't care, right? That's their problem not yours.
>> Brian: Okay, so let's try this again. So firstly you have to restart your watch.
>> Brian: It's gonna take even longer now cuz we're linking all of our files.
[00:04:36] We just added like another one point two seconds on it or something like that. So let's go introduce let's go put some semicolons in here because we're naughty children or something like that except that's the other thing I forgot about this is Webpack's actually smart enough to say you put in semicolons that's going to make zero effect on your code so I'm just not going to rerun right now because it doesn't actually matter, right?
[00:04:59] Webpack's actually kind of smart like that, so we're gonna put in some text string modifications because that is significant. And now if we run it again we're going to get errors here. So, I think the good news here is that it actually does still rerun right so you actually do get this because Lint errors aren't gonna crash your programs most of the time, right.
[00:05:26] But it is going to let you know this is a problem, please fix that. So just the way that you read this. This is line one column 31 line two column 38, so it actually points to you, this is where you're wrong and so now if I go take those out, it'll happily re-compile.
[00:05:47] So now we have Standard running all the time.
>> Speaker 2: Can you quickly go over to the preloaders versus loaders?
>> Brian: Sure, preloaders get run first, that's the gist to that one.
>> Brian: And again, the reason why we run that first is, we don't want to compile it first before we run Babel, or before we run the Linter on it because we don't actually care if the compiled code passes Lint, it won't, right?
[00:06:15] That's the point, especially if you uglify and minify it, then it's definitely not gonna pass Lint. You actually just only care about your codes you Linted first, and then you compile it.
>> Brian: Cool, other questions?
>> Speaker 2: Can you upload the latest to GitHub?
>> Brian: Yep, I'll do that, here in just a sec.
[00:06:44] Actually I'll just do it right now.
>> Speaker 3: If you have multiple loaders or preloaders do they get run in the order in which you define them in the config?
>> Brian: Yes. I believe that's the case. But you wanna check.
>> Speaker 2: So preloaders actually get run at a different point in the life cycle?
>> Brian: Yeah you're guaranteed anything that runs in the preloaders get run first. And the nice thing about that as just, yeah, you probably could just put that instead of loaders here, but the I think the basically the idea is preloaders is there anything that to me doing like checking your style making sure your tests are running right and the load is reaction to be like modifying the output of code right that's the basic gist of what's going on.
[00:07:38] I think there are post loaders as well maybe that might be like uglify or something like that, not sure
>> Brian: Okay.
>> Brian: And so that just pushed up FEM 7 for those that need it, hopefully Here we go.
>> Brian: Hopefully GitHub doesn't go down again.
>> Brian: All right, so that's, [COUGH] kind of my additional spiel on ESLint, as well as on updating Webpack, any questions on ESLint, Webpack before we move on at all?
[00:08:36] I guess one thing I wanted to address, just so you don't think these are appearing out of nowhere. So this extends, where that's coming from. If you look at your package.json we have ESLint config, right that's where these are coming from, so you have Standard and reactors that are being brought in and-
>> Brian: We could do JSX, but just you know that reactor's including JSX, just like how they're peer dependencies is what they are so you just include Standard in Standard React and you'll get all the rest of them that are being brought in there.
>> Brian: Okay.
>> Brian: So that's how that works.
>> Brian: Okay, cool. Well, we're going to work on React Router now, unless anyone has any other questions.
>> Brian: Is everyone having Webpack watch work okay? Are they seeing Lint errors? When they invent them, cool.
>> Speaker 2: Somebody is asking about can you explain peer dependencies?
>> Brian: [LAUGH] I don't want to but I can.
[00:09:52] I'm going to give you like the 30 second version because this is definitely not a React workshop or sorry, it definitely is a React workshop, definitely not a node workshop. If you have further questions definitely check out Kyle Simpson's node workshop cuz it's the best. So you have in your package update Json, you have libraries that you depend on, right, that that must go out to production.
[00:10:19] These are ones you're actually using in your app. So that basically when you're compiling to be run on your server these are all ones are getting included. Those are dependencies you have dev dependencies these are ones that you are using to actually compile your code to add to bug ability to your code right like you don't need a Mocha in production which is our testing framework you don't need Webpack in production.
[00:10:43] You don't need any of those things. The idea of a pure dependency is, I have React and then I also have React Router right? React Router makes zero sense by itself it needs React to work correctly, so React Router has a peer dependency on React. That they need to be both included into a project.
[00:11:01] That's the gist behind a peer dependency. Their giant,just mess and node, in fact a lot people are encouraged not to use peer dependencies. But I'll leave that for you all can go read Hacker News and argue with people on about the internet cus I don't want to.