Browsing the Updated Library

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

[00:00:04]
>> Kent C. Dodds: Anybody have any questions?
>> Speaker 2: So a question on security. Earlier you were talking, just because you've opened it to whatever.
>> Kent C. Dodds: Yeah, anything, yeah.
>> Speaker 2: So you mentioned maybe someone putting a virus in code or something like that. Is there any type of-
>> Kent C. Dodds: Possibility of that happening.

[00:00:21]
>> Speaker 2: Virus scan, or anything to prevent them from happening?
>> Kent C. Dodds: Yeah, that's a good question.
>> Speaker 2: And then another one, in your experience, have you seen something get injected like that before, or have you heard of that happening, with [CROSSTALK]
>> Kent C. Dodds: Having a virus as part of an OM module?

[00:00:39]
>> Speaker 2: Yep.
>> Kent C. Dodds: So I can tell a couple stories, or one story in particular comes to mind. So there is an attack vector that is available to anybody right now. And that is because most people don't lock down their versions. Anybody who has a widely used NPM module could really a patch version that does the virus thing.

[00:01:08]
And then because nobody, or many people, don't lock down their version numbers, then you pick up the patch version and boom your infected. So that's one argument for lucky numbers and numbers and using shrink-wrap as well. So that's kind of scary a little bit. Actually, somebody wrote a blog post about how easy it would be to write a virus that gets your NPM tokens, and then gives it to them, and then they have access to publish on your modules too.

[00:01:48]
And so they publish patched versions on all these modules, and poof, the whole world is burning. So yeah, there's definitely an attack vector that's kinda scary from that perspective. And that's not really a solved problem. As far as past experience with people really messing everybody up, yeah. Left pad is something that some people may have heard of.

[00:02:11]
It was a couple months ago. Some disgruntled open source contributor got upset at NPM for something and decided that they didn't want to participate in the community anymore. They had a module that was like 10 lines long that takes a number or takes a strain and adds a left padding to it.

[00:02:34]
So like you pass it a number of like 23 and then you say I want to left pad it like five spaces and it will turn it to one, two, three, 23. Right? So pretty small module, but Babel uses it for some reason. So when they unpublished that module, then Babel broke.

[00:02:57]
And because it was a transitive dependency of Babel and Babel had it listed like a version range with a carrot, then everybody else who install Babel, thereafter, their NPM install failed because that package is no longer on the registry. And the world was blowing like exploding and like fires and everything for about an hour before things were resolved.

[00:03:21]
And so I don't think anybody died, but it got everybody to think like okay, so what do we do in situations like this? So the result was NPM decided that you can unpublish a module from NPM within 24 hours after publishing. That saves you if you accidentally publish something with your tokens or something like with, you know, something that's critical to your business or something.

[00:03:50]
But thereafter, you have to contact support. And if you have any dependencies that are on, or anybody's downloading your module ,then they're probably gonna say no. And you'll just have to update your tokens. If something like that happened you just have to invalidate all that information. So I think that was a good call from their perspective, how to respond to that.

[00:04:17]
Like as far as policy change goes. We want the registry to be immutable so that we can protect ourselves from attack vectors, like unpublishing something that's really important, or publishing over on top of another version. But yeah, the attack vector of transitive dependencies and publishing viruses as patch versions, yeah, that still exists.

[00:04:41]
Nobody get any ideas. [LAUGH] So cool, any other questions before we look at hopefully a successful release. Okay you're all just waiting, did it work? Okay so we reported the coverage and then we run release. Generate a change log in front of, yeah key click handlers. So it looks like that's the output that you get from NPM publish.

[00:05:05]
So it did release a new version and it generated change log from one commit. So if we go to github-names then we'll see we have 2.0.3 released. And if we actually, just for the fun of it, we'll view the code. We'll look at the package, my goodness. Did you see that?

[00:05:29]
Where's my dist directory? Wait, I'm looking at version two. Whew! So it looks like NPM's CDN's cache hasn't been updated yet. But, there we go. Woah, that like terrified me for a second. But, yeah, we look at our package.json, and we see it's not semantic-release, it's the actual version.

[00:05:49]
So that's awesome. Now, let's look at our GitHub repo. So we'll go to, actually, we have a link right here.
>> Kent C. Dodds: And, we'll go to releases and, boom. We have a tagged release that has our change log in it. People can go look for more information at this to see what actually changed.

[00:06:13]
And, I didn't have to do anything more than just, this kind of follows the same idea of tie your hands to free your mind. It's like tie your hands to free your time. So if you can commit yourself to following a couple of conventions, then it can really save you a ton of time and having to run deprecations on things when you forget to run builds and stuff.

[00:06:37]
So yeah, that will happen automatically. And that's pretty much it as far as slides and things go. The next thing we're gonna talk about is community. So I'm gonna just leave that open for questions.
>> Kent C. Dodds: So Denarte is asking, what should be in any breaking changes or issues caused by this change?

[00:07:05]
So and if I go back to validate commit message to find that link. Here,
>> Kent C. Dodds: List any what is it? That was actually a commit as in question. So the committ as in question is list any breaking changes or issues caused by this change. And that goes in your footer.

[00:07:30]
So that is what goes right here. And this would be anything like, let's say somebody reports an issue with your library and you're fixing it. Then you would say, okay, this closes issue number 300 or whatever. So you would say closes number 45. And then GitHub will automatically close that issue for you and that commit is merged into master.

[00:07:54]
And if you have breaking changes associated with this then you'd say, BREAKING CHANGE: random changed to getRandom, would be an example of that.
>> Kent C. Dodds: So any other questions? Question from Bret, any reason my Travis CI is now not kicking off the build. No Travis setting issue, potentially one of my scripts slash hooks.

[00:08:25]
Not likely, I'm not sure what that could be, Bret. Maybe we can chat a little bit after or something. Sorry. You can ping me on GitHub issues or something. I feel like there is probably room for me to talk a little bit about, or address the question that people often have about frequency of releasing.

[00:08:49]
So people often ask, okay, so now you're releasing on every single commit? Isn't that a little bit much?
>> Kent C. Dodds: So yeah, maybe it's more than many libraries release, but I'm of the opinion that pretty much the only reason we don't release every single commit is because it's not easy to do.

[00:09:12]
And so by making it easier if you just take a step back and say, if it was painless to release on every single commit, why would I not do that? And I can't think of a reason. There's one situation where I would maybe postpone releasing, and that's for breaking changes.

[00:09:30]
Because maybe I wanna queue up some breaking changes all together so I don't reach version 25, and people are constantly trying to update their code to deal with breaking changes. So it's nice to have your community only deal with breaking changes once, even if there are multiple breaking changes in a release.

[00:09:49]
And so the way that you manage that kind of a thing and, I did this recently with one of my packages, is you create a branch called next or beta or whatever want to call it. And then all commits that are breaking you make pull requests to that branch.

[00:10:04]
You continue to do that until you're ready to release it, and then you make a pull request from that branch to master. And you merge that and all those commits suddenly get to put into that release and semantic release will say, wow, look at all these commits. And those are all released together.

[00:10:22]
So if you do want to batch up releases and have a big marketing, celebrating thing. Then you can just have all of your pull requests go to a different branch and then release those out when you're ready to actually release that, just merge them into master. So the process of releasing has changed from running scripts to merging to master.

[00:10:46]
Yeah?
>> Speaker 2: And I think you made a comment earlier about how you no longer commit to master. Is that?
>> Kent C. Dodds: Yeah.
>> Speaker 2: So, can you explain that?
>> Kent C. Dodds: Yeah, so the comment I made earlier was you never force push the master. And that's generally a good idea. If you force push the master, your co-workers will not like you, and the reason for that is what you're doing is you're taking the code you have and putting it up on master regardless of whatever is up there.

[00:11:11]
So if somebody else had pushed up some code to master, you're overriding their changes, not a good idea. But what you said is correct, as well. I generally try to avoid pushing directly to master. I try to make pull requests, a well, and that actually segues into the community aspect of things that I'm gonna talk about here in a second.

[00:11:32]
But this is, what I try to do, is I try to encourage other people to review my code even in my own libraries. That helps builds community. So unless anybody else has further questions, I'm gonna just jump into this little chit chat about community.