npm npmCamp Presentations (2016), 30 Aug 2016

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: npmCamp 2016 - Lightning Talk - Automating SemVer for Fun and Profit: ... by Andrew Goode

Description

Lightning Talk - Automating SemVer for Fun and Profit: Tools and Practices to Make Releasing Easier by Andrew Goode

A

Hi, my name is Andrew good I am I work on the registry team at the NPM, which is a great honor, and today we're just going to be talking a little bit about something, that's a little near and dear to my heart, which is helping to make releases easier using NPM. This is almost a talk that just piggy backs off of what Steve did earlier. So I really appreciate his talk, so also just a little disclaimer.

A

This presentation is a little bit of the product of when you're up till about 3am the night before you're supposed to be giving a talk and trying to figure out what you're going to say, anywho, it's. Basically a dialogue between me and my alter ego.

A

All right, so alter ego, we're going to be automating, some bar for fun and profit fun, one. You say: okay well sure, because open source is fun. Anybody doesn't actively work on open source projects. I highly encourage you to do so. It can be tough sometimes, but I think it is highly rewarding and profit. You say hmm how does that work? Well, kinda. So the message also applies to your day job, so anybody that regularly work uses NPM or regularly works with packages and needs to publish those packages.

A

This message is for you, okay, you got me I'm listening. How do I automate some very good question? I can answer it with three words: structured, commit messages: okay, okay, okay, hold on, I know I just lost most of you in the room structure commit messages that means more work and kind of invades on my creative space here. Come on. These commit messages. Are mine?

A

Ok, ok, let's just bear with me for a second, let's go over what exactly I mean by this we're going to do the lazy man's version of structure commit messages and it still works. So what does that mean? First of all, we're going to defer the structure in the commit messages until they're absolutely necessary, which happens to be when you're just about to merge your change into your master branch.

A

So here's the idea behind that the normal workflow right is. You can still stick with your witty everyday commit messages. Here are a couple examples: Lock s-foils in Attack, Position late evenings revert commit if yeah.

A

So so you still get your same. Where do you commit messages? You push your changes up to github or what have you you open? Your PR, you do a review. Maybe there's some back and forth between things are not quite right. That I need to make some more changes. That's fine notice! We haven't done anything out of the ordinary, yet all right this should be. This should sound familiar they step so far. So we're now to the point where we have reviewed change.

A

Its looks good, we're ready to merge it in and make it an official part of the code base. So this is where we have deferred our structure until this point in time. So what do we do? Two key things we're going to use if github I don't know if you heard recently, but the past couple months, several months actually now github added this cool feature to their UI, so that you can have this option with how you want to do your merge when you're merging a change from a feature branch to your main development branch.

A

Typically, you would always have to do just a standard, git merge and, as everybody knows, that means you're actually adding a new commit on top of the existing commit history right, so you're keeping all of the existing commits and there's adding one on top of it to get back to the branch that you want it to be in the squash and merge feature, though, is pretty cool, because this allows us to basically scrap the histories of the feature branch squash.

A

It all down into a single commit message with a reference to the PR that we are merging, and in doing so, we can easily throw in our structure into the commit message at the very last second, and so my second point, if you're still need convincing, is that structure is actually really easy again we're doing a my version of obstruction, which is the easily the lazy man's version.

A

So what that means is you? Basically, all you have to do is if this is a new feature that you're adding to your project, you just prepend a feat to the beginning of the commit message, the one that we're going to be squashing and merging. If it's a bug fix just append fix the only other thing that really matters is, if it's a breaking change, if it's breaking change, just include the words breaking change somewhere in the commit message. Typically, this would be like in the main body.

A

We'd want to have a little bit of explanation, but again we're being lazy. So we're just going to throw this in like a detail and by the way for those that don't know these are what these are commit message: conventions that were developed by the angular project and so I'm just kind of adopting these as as a good practice.

A

So here is an example right I have this feature that I've developed I'm applying I want to apply my end globally, so I you can see I've got. My green button here says, confirm squash and merge. If you can see that against the white background and I just appended a pre-printed feature to my commit message: easy peasy, that's it: okay, okay, okay! So so what I thought we were talking about? Automating things here, I so far, I've seen any automation, I always seen is some extra work.

A

Okay, good question! So I want to introduce you to this simple little CLI tool. It's called standard version.

A

Basically, what it allows you to do is before, when you were ready to cut a release for your project and your package that you plan to publish to one or more registries kind of your best version. Your best option was to use NPM version command and you had then you had to you had to give it an argument right. You had to specify something for impian version.

A

You can specify that hey I want this to be a patch or I want this to be a minor bump or the major bump, or you can just specify the actual version you want to be, and that's kind of best case scenario right is using the CLI to do this for you, which will automatically create a get tagged in your git repository as well now, even before, even before you knew about this command, you know perhaps you're just editing package.json by hand, we're looking for a better system here right.

A

So one of the problems with this, in my opinion, is at the time of which you're ready to release your project to publish a new version. This may be days weeks months after you've accumulated some some things that you've some changes that have been made to the project, and so now that you're ready to cut a release. I got to go back in acts, think about what changes have been made after they've been made.

A

What, if I don't remember, I got to go back and look at the commit history or I got to go back and review the PRS that were merged again we're wasting time here. So what standard version allows you do now that we have structured commit messages?

A

All I have to do is run standard version and I don't have to think about the version bump at all right, which is much better because now I don't have to think about I. Don't want to worry about what changes were made at the time that I'm ready to publish I already made the the tough decisions previously.

A

So at this point, no thought is required right. I just have a single command, and it's going to do all the nice things. The MPN version does for you already, which is bump. The version in your package.json file commit that change to your master branch, go ahead and create a tag for the new version, just like mpm ver to the standard impune version command.

A

Only this time, no thought is required, and this is also beneficial right, because the when you made the changes you, what you don't realize possibly, is that you already made the decisions for what your next version was going to be. When you were doing your merge, when the changes were still fresh on your mind right when they actually, you had some cognitive recollection of what what the changes were. So when it's time to cut our release, you let the get you like to commit. History speak for itself and.

A

So my alter egos thinking hmm wait. That's seriously! That's all there is to it. Actually it gets even better if you call within the next 23 and a half minutes we'll throw in a changelog for free. So so yes, so what that means? Is you not only get automatic version bumping don't have to think about it. You also get a nice change. Login for anybody, that's maintained, open source project and manually maintains a changelog. It can be frustrating right, it can be difficult. You can spend valuable time and effort.

A

Copying. Basically copying your PR list over to your change log and making sure you get all the references right make sure you have some notes in there and give credit to the people that worked ribbing to your project. Well, now you don't to worry about that. You get that for free, so this is an example changelog created by a Santa version right so again, my point is you: did the hard work up front when you will you actually start using structure, commit messages and you're letting the commit history? Do the work for you right?

A

No more manual. Changelogs is cool.

A

So yeah it sounds good I, like the sound of that. So what was what was that tool again like sorry, I was. I fell asleep there for a second standard version, all right, so we're kind of piggybacking off of the the standard name, which is a code blender, and we are we we checked with with Ferris. He gave us the go ahead to to use the standard name, and so, if you want to use it, it's really easy right. You can install it as a dev dependency in your project.

A

If you want to make sure if your project is more portable, you don't have to worry about people setting up things in their global environment, to develop on your project, I'm sure, no problem, salt as Deb dependency, add a at an NPM run script and just kind of the standard thing that we've been using so far is is a release command.

A

So what that looks like is NPM run release when you're ready to cut a release, that's it or if you want to keep an extra Deb dependency out of your project, you can just sort all it as a global bin with NPM I dash G and just run it using a CLI easy-peasy.

A

So that's, basically it alright leveraging the power just a simple little automation right just to spare you a little bit of cycles because, as everyone knows, our time is valuable, and so here's a simple little library that you can use to easily help you cut releases without having to think too hard about snugs and and you get the changelog generation for free, so standard version is what I would call an opinionated library, because we expect you to use angular, commit conventions and the look. It only makes changes to your project locally right.

A

So what that means is it's only touching your git repository that you have cloned on your machine doesn't actually publish anything for you. It doesn't actually push anything for you and that's just so that you can. After you cut a release, you can verify things manually if you want to before you publish them.

A

Everything is good if you're interested in a more yet more automation, which I think is probably a good idea. You should definitely check out semantic release, which I know you've, probably seen once or twice on I'll period I mentioned today, and we have the privilege of having the author speaking here in a little bit.

A

So that's pretty cool he'll be talking about something different, but so basically that's it. That was my lightning talk. Get some good on time. So again, have any questions feel free to come and ask I'm excited to talk about this. You can find me on Twitter or on github as next true or you can email me directly in android NP MJS com thanks.