Publishing to npmjs.com

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

[00:00:04]
>> Speaker 1: So now we're gonna set up automatic releasing. So before we set up automatic releasing, I think it would probably be great to do two things. First, let's go ahead and just publish it ourselves without automatically releasing. And then we're gonna take a break and then we'll set up automatic releasing.

[00:00:20]
That sound good to everybody? Okay, any questions before we do that? Yes?
>> Speaker 2: Can I just go back to the core code stuff?
>> Speaker 1: Yeah.
>> Speaker 2: That token, upload token, do we need to add any of that stuff or is this really just on?
>> Speaker 1: No, you mean for semantic-release or for cryptic?

[00:00:37]
>> Speaker 2: No, are we still only in the travis.ei stuff, or do we have to go into cocoa itself and-
>> Speaker 1: Yeah, you shouldn't have to do anything with cocoa, yep. It should just kind of magically work. As long as you had an account with cocoa, but I'm not sure what it would do if you didn't already have an account when you push it up?

[00:00:59]
Any other questions? Okay, sweet. So yeah, like I said, let's just go ahead and release something so that you can feel like you, even if you aren't able to follow along for the automated stuff, you can at least see how you would release something. So the way that releasing works is pretty straightforward.

[00:01:25]
First, you need to login. So we're gonna go to npmjs.com. And if you're not logged in, log in. If you don't have an account, get one. Once you have an account, then you can go here back to your terminal and type in npm login. And my username is prefilled cuz that's in my npm RC.

[00:01:49]
And I'm gonna enter my password, which I totally now can't remember.
>> Speaker 1: Add your email. Sweet! I remembered my password, phew. And now you should have a token in your mpmrc file in your home directory. Don't show that to anyone. Is everybody able to follow along to that point?

[00:02:26]
>> Speaker 1: Okay, so now that you're logged in, you should be able to publish this. Just make sure that, I totally forgot, my description is wrong. So update that. Star Wars should be, GitHub usernames, yep, that's more accurate. Update description great. So with this, now we can run npm, publish, hit Enter and [SOUND] it's running npm pack, and it uploads the zipped file and now github-names is published.

[00:03:12]
I wanna hear a giant cheer when you publish yours like, whoo!
>> Speaker 1: And if you go to the npm registry, npm.js.com/package/GitHub names or whatever names it is. Then you should see your package.
>> Speaker 1: So again that was npm login. You fill in your username and password and your email, then run npm publish.

[00:03:53]
>> Speaker 1: You got it?
>> Speaker 2: Well, I published it, but it was garbage so-
>> Speaker 1: [LAUGH] [LAUGH] oops [LAUGH]. Yeah, and I totally forgot. You're probably gonna want to run the build before you publish this. This why we automate releases so we don't forget steps like this. But if you hadn't already run the build, then that's definitely something you just run validate.

[00:04:21]
And then you can publish. If you want to publish an update, then you need to update the version here. So yeah, there are a couple ways to do that. But I'll wait for a little bit while people are still publishing. If you have your package published to npm, then I want you to go to the chat.

[00:04:43]
It's a live event. And paste in the URL to your module.
>> Speaker 1: Sweet.
>> Speaker 1: I love it. This is awesome. Somebody put an awesome GIF on like all kinds of docs and stuff, yeah, just. Updated the README from the original project, good for you. Who is this? Awesome, good job.

[00:05:30]
Good job, everybody. We've got some awesome new modules here. So one thing that you're not gonna see, probably for you but I have for me because I have a Chrome extension that does it. But there's this new code link. What this does, is it takes me to a service called npmcdn.com for that module.

[00:05:49]
So if you go to npmcdn.com, then it will explain that it's a content, or it's a CDN for pm packages, and it basically serves up what is on the registry. It's super awesome, and what it enables us to do is I can go to this random animal names and explore the folder or the directory of the disk and all this stuff.

[00:06:14]
I can even change the version right here, which is a new feature that's awesome. But, yeah. So if I looked at the random animals names, JSON. That's served to me as JSON. Then I can look at index.umd.JS. And that's the library right there. So I'm gonna take this URL, go to a JS Bin.

[00:06:40]
And add a script tag up here where the source is that. And let's see what was, it's called random animal names on the global, so this is say, console.log.random. And instead of output, I'll look at console and I'll run. Boom, and I'm getting this from, whose is this?

[00:07:14]
The random animal names.
>> Speaker 1: From Brett. Brett, thank you for your library. I'm using it in a JS bin right now. And that's because we had a browser base build that works. And we can now make demos out of it, and you can make examples out of JS bins, and put those examples in our documentation.

[00:07:34]
Or you can use a JS bin or code fan or whatever floats your boat. But you can just do it all on your browser which is super slick and it's all using NPNCDN.
>> Speaker 1: So that's that. Any questions? Looks like plenty of people have been able to at least publish modules.

[00:07:53]
Yeah. And if you'd like to unpublish, you can do that for the next 24 hours. If you wait for more than 24 hours, you have to contact NPM support. Okie doke, so I'm back and Ivan is asking you a question. What about when there's a little command? How do we manage that?

[00:08:09]
So the question is asking about if you need to make an update to your package just for the smaller tiniest little thing, can't I just over fix a previous Publish. And no, yeah, even if it's just a single line in the README, why do I have to make a whole new version just to fix something in the README.

[00:08:32]
There are a couple of reasons for this. The biggest is for safety, for the safety of everybody who uses npm. If somebody could just force push on top of another version, an existing version, that would be a really dangerous thing for the community. Just as an example, let's say that I get really frustrated with a community and so I want to do something really mean, and I have a package that has hundreds of thousands of users.

[00:09:01]
And it's a transitive dependency. So most people don't even know that they're using my package. So I could install a virus as an install script, so any time somebody installs my package it installs this virus on their computer, and I could cause some serious damage. And then just go up and publish a new version of my package, and boom, I've got everybody's bank accounts.

[00:09:27]
That's not very nice. And so having the ability to lock down versions and make a package manager immutable is a really important feature for package manager. And so from that security perspective, you cannot publish on top of an existing version. So hopefully that answers the question pretty well.

[00:09:49]
As far as the version and the numbers and everything like that. Let me take a quick pause and talk about what this version number is. So if we go to semver.npm, well, no, no, semver.org, I think. Yeah, semver.org. Yeah, this is semantic versioning 2.0.0. It explains that this version number that you see here is represented by three individual numbers that each have a different meaning.

[00:10:24]
Let me bump this up a little bit. First is the major, so that's the two here. And a major version is when you make incompatible API changes. It's for breaking changes. Anytime you say, hey, you will have to change your code to continue using this project, that's when you bump the major version.

[00:10:42]
For a minor version, it's like I added functionality, or maybe I didn't extend the API any but I improved performance or something like that. Well, even performance would more likely be a patch. But it's generally something like I'm exposing more to you. But in a backward compatible way.

[00:11:02]
And then the last number, the patch, is when you make a backward compatible bug fix. So again, the key here is the second two numbers are backwards compatible. Any time you break anything and you force somebody to make changes to their code, even if they're small changes to their code, then it needs to be a major version bump.

[00:11:21]
This is a contract that you as a library author you make with the users of your library. And then there are other ways that you can alter this a little bit for beta versions and stuff and you can read more about this on semver.org. But this is a really, really important concept in the NPM community, and I recommend that you think about this very closely.