Sending the Distribution to NPM

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Kent C. Dodds: So, now that we are transpiling, what we want to send to the npm registry is the dist folder. So, I'm gonna show you a really handy thing that you can do, to make sure you know what you're sending to npm. And, then there's a command called npm pack.

[00:00:26]
As part of the publish script that npm is running when you say, okay, publish, one of the first things it does is internally, it runs npm pack. So that it creates a zip folder. And then that's where it gets uploaded to the npm registry. And so if you're ever wondering what am I sending to the registry?

[00:00:47]
Then you can run MPM pack and then it open that zipped file. That will create a folder called package. And in here you'll see everything that you're sending up there, which is most of the things that we have in our project. Let me zoom in a little bit.

[00:01:04]
So we have our test directory, our source directory, our README, our package.json, our LICENSE, dist, and CODE_OF_CONDUCT. So, we don't care about sending either one of these two directories, the source and the test, we don't care about sending those. README is probably, that's a pretty good thing to send.

[00:01:21]
Code of conduct probably doesn't really need to go with our distribution. That's more for like the management of our repo. The license is probably a good thing to send. And package.json, obviously is required for Node to be able to resolve what our main file is. And then we're sending the dist directory.

[00:01:40]
And that's actually pretty much the only thing that we really want to send. So, we need to somehow get rid of these extra files that we don't want. So how do we do that? Well, there's a really easy way. In our pckage.json, we can configure npm what files matter for the registry.

[00:02:01]
And we do that by adding a property. We will stick it right here, it does not really matter where it goes. We'll say files as an array, and the only item in this array will be dist. Read me is included by default and so is license. I'm gonna delete the package and that previous zipped folder, and we'll rerun $npm pack command, and reopen that a new zip folder.

[00:02:34]
And you'll see dist, license package, JSON and readme, that's everything that we need. I'll go back here so, we can see what I ran.
>> Kent C. Dodds: Anybody get that working and seeing what's in that package?
>> Kent C. Dodds: Anybody have any questions or anything, need help?
>> Kent C. Dodds: I'll give an air five to the first person who says that they got it working.

[00:03:19]
Yeah, boom. Awesome.
>> Kent C. Dodds: All right, and Denarte, awesome, good job. [LAUGH] Okay, cool, so that's pretty much it as far as what we're gonna work on together. I'm gonna show you just two other kind of boiler platey things. That you're gonna want to do as well. And that is, in our ESLint.

[00:03:50]
We're gonna add some best practices for ES6 code. And import statements, things and in our, let's see there's one other thing I thought. Yeah, this is super duper super important. So everybody look here, this is really important. So now that the, actually I can demonstrate why this is so important.

[00:04:12]
So if you opened up that starWarsNames zip file, then you're gonna have a package folder, that's where everything lives. So if I ll that package directory, then you're gonna see the package.json and everything that we need, that directory has our trans file source code. So if I zoom away, if I run require package, and then it's gonna look up in the package.json, and find out what the name is, and give my package.

[00:04:41]
This would be, just like if I published to the registry somebody installed it and they said require starWarsNames. So this is just going to give me whoops package directory. There we go. Now that's funny. Let me rename that package directory. So we'll rename it to starwars-names-package. Why did I name it something so long?

[00:05:12]
Okay, so we're gonna require star-wars-names-package. And it's gonna blow up for us, cannot find module starwars-name-package. The reason for that, is if we use CD into the starwars-name-package and we cat the package.json, then the main that note is using to determine what file to give us when we require it, is pointing to source index.

[00:05:41]
If we look in this folder, we don't have a source, we have a dist. So we need to update that. That makes sense why that matters? Why it's very important you get that right. So, we'll just change that to dist. And if we run npm pack, and then open starwars-names folder.

[00:06:00]
And we'll rename this to other. Whoops. Like things are all messed up now.
>> Kent C. Dodds: Okay, I'm all kinds of confused. There we go, we'll do pack again, and open it.
>> Kent C. Dodds: Where on earth am I? I'm in my trash, that's funny. I know where I am. Get out of there, there we go.

[00:06:26]
Now we'll pack it.
>> Kent C. Dodds: Okay, cool, so we'll get rid of these guys and change this to stn. So now if I go node and require stn, then I'm gonna get what I need.
>> Kent C. Dodds: Cool, any questions?
>> Kent C. Dodds: Okay, so on the chat we have from Brent, I'm getting multiple duplicates of the package in the same tar file.

[00:07:00]
I don't know why that would be. Sorry Brent, maybe I need a little bit more info. Irvin is asking, can't now run npm run watch test? That is true, because now our code is being authored in ES6. If you start making changes to your code which we're gonna break for lunch, but I'm gonna let you work on that if you want to.

[00:07:27]
Then you're not gonna be able to run you test, because your tests aren't able to run that code. We need to transpile our test, and that's what we're gonna do next. So, yep, I think that's pretty much it. So I'll just, to wrap up for lunch, if you want to, you can go to your index JS folder and start doing a bunch of ES6 stuff.

[00:07:56]
One thing that I add here at the bottom of the file, is this module exportse=mainExport thing. So I turn object into or turn the module exports into an object called mainExport. And then I export that as the default, and I also say module.exports = mainExport. If you want to know why that is go to kcd.im/tears.

[00:08:20]
And that will take you to my blog post that explains the tears that I experienced, when I learned why this is important.
>> Kent C. Dodds: So I'm not gonna get too far into that. You come can to my Midwest JS talk on Thursday or Friday this week. I'm gonna give a talk entitled, More Than You Want to Know About ES6 Modules, and I'll explain exactly how this works.

[00:08:44]
Okay, yeah?
>> Speaker 2: Just a question that package.json. So you updated the package.json that was copied into the dist folder. Is that correct or not correct?
>> Kent C. Dodds: Did I?
>> Speaker 2: Well, I'm not sure of that. What I'm wondering is so that update, is that to the actual package.json in the root directory?

[00:09:04]
>> Kent C. Dodds: Yeah. It should be, yeah. You'll obviously.
>> Speaker 2: Does that change how.
>> Speaker 2: Does that change what JavaScript has instrumented, during test, so-
>> Kent C. Dodds: Okay, great question, no, so the JavaScript that's instrumented during, I know for testing, is the one that we've specified in our mocha.opts here. So that, well, sorry, to be more clear, the way that NYC works is we have it kind of wrapping the Mocha CLI.

[00:09:34]
So NYC will say, okay, like you're starting me up. Now I'm gonna take the other arguments that you gave me. And anything that I don't care about I'm gonna just forward on to, or I'm gonna like expand those as a separate process. Then I'm gonna watch what that process if requiring and doing.

[00:09:50]
And anything, any files that it requires that I'm not going to exclude, anything it excludes things in node modules and anything we specifically tell it to exclude. It has those defaults that we talked about. So anything that is shouldn't exclude, that this separate is requiring, it's going to instrument it before it hands it off to that process.

[00:10:11]
That make sense?
>> Speaker 2: So you're testing your source and not your-
>> Kent C. Dodds: Yes.
>> Speaker 2: Dist. Now your dist, though, is actually, it's-
>> Kent C. Dodds: What you're sending to users, right?
>> Speaker 2: And it's in a sense it's different code. So, you're making the assumption that Babel is tested well enough that you can-

[00:10:29]
>> Kent C. Dodds: Yep, that's exactly the assumption that I'm making. Yeah, I'm glad that you brought that up. I was, yeah, that's definitely something that you should think about. For sure in my opinion, you should for sure be testing your source code and trusting your tools. But in that same vein, doing integration tests is a valuable thing too, so using something like Don't Break.

[00:10:52]
Would be really valuable in that kind of scenario where you say okay, after all the tooling is all done doing stuff with my code, does it still integrate well with the tool, other things that are using this module. And so if you're concerned a little bit about whether you're tooling is set up correctly or something, then you can do some integrating test and that's a really valuable thing to do.

[00:11:16]
You get a lot more bang for your buck with integration test, there's just a little bit, in some cases there a little harder to set up.