Sweetalert2: Add semantic-release to improve the workflow

[toverux]

Recently I've used semantic-release on three packages I own. It's a pretty cool tool that enforces good versioning practices, as well as conventionally-formatted commit messages, etc.

Main features:

• Automatic publish on npm after the Travis build succeeds ;
• Version management of the package: no need to calculate what will be the next version by hand, semantic-release parses the commit messages (documentation) and sets the new version ;
• Generates a changelog and creates a GitHub release with it. Also tags a version on git. See an example of the generated output here.

Example of commit messages, given that the current version is 1.0.0 and the push is done before any other commit:

fix(some_module): no longer display things that souldn't be displayed

bumps the version to 1.0.1

feat(some_module): implement things

bumps the version to 1.1.0

feat(some_module): move to a fluent API

BREAKING CHANGE: the ancient API no longer exists.

bumps the version to 2.0.0

Now you can create a new branch for a new feature (ie. a PR) and do that:

fix(some_module): fix things up
feat(another_module): add myMetyhod()
feat(another_module): added a new alert type

When the branch gets merged into master, semantic-release will bump from 1.0.0 to 1.1.0. Which is exactly how things should be. It's exactly what we're doing now, but standardized and automated.

We could also use commitizen with it to enforce good commit messages (we'll need to warn our contributors to respect those guidelines).

I'm volunteer to sumbit a PR that adds semantic-release to our workflow (just a few lines of configuration, no CLI tool to run evertime, it's fully automated and runs on Travis).
Your thoughts?

[limonte]

Totally love both semantic-release and commitizen! Thanks @toverux for creating this issue :beers:

Please go ahead with the PR which will significantly improve our workflow.

[limonte]

Hello @toverux, hope you are doing well!

I changed my mind about commitizen and semantic-release. There are a couple of reasons but the main one is the contributor experience. I don't want to force our contributors to follow any strict rules about commit messages. The contribution should be as easy as possible for the community.

Also, automatization could easily break things for us. For example, in the latest bump-commit https://github.com/limonte/sweetalert2/commit/742fc95280d6d986778c168d8bb5ef6afb3bb8ce I had to fix the JS minification step in config/utils.js as uglify-js dependency was updated from v2 to v3 without backward compatibility (https://github.com/mishoo/UglifyJS2#note)

semantic-release is a great tool for bigger projects with at least several people in core team, but for this small lovely plugin like swal2 I'd like to keep manual gearbox, at least for now :)

Anyway, thanks for mentioning the automated publishing because I didn't know about that, hope you are enjoying this weekend somewhere offline and not working like I do :)

[toverux]

No problem, I understand your position :) It was a proposal, that's also why a made an issue to discuss rather than a PR.
I will close this, feel free to reopen if you change your mind someday!

[zenflow]

Also, automatization could easily break things for us. For example, in the latest bump-commit 742fc95 I had to fix the JS minification step in config/utils.js as uglify-js dependency was updated from v2 to v3 without backward compatibility (https://github.com/mishoo/UglifyJS2#note)

@limonte Sorry can you tell me what this problem..

https://github.com/sweetalert2/sweetalert2/blob/742fc95280d6d986778c168d8bb5ef6afb3bb8ce/package.json#L27

has to do with commitizen and semantic-release?

[zenflow]

We could probably use semantic-release internally and just format the commit messages during merge, but i don't know if it's really necessary. Knowing if it's a major or minor or patch is not that hard to do manually.

[limonte]

After https://github.com/sweetalert2/sweetalert2/pull/857 it should be much easier to implement auto-releasing process.

[toverux]

@zenflow It's not just about the version number! https://github.com/semantic-release/semantic-release#release-steps
I know you know, but really, if it was just that I wouldn't use it. It's a pack for automated releases and it does it well. Like I said, I just press "push" on Git, and done.
We can also add our own plugins as semantic-release steps, which is very practical. Or find third-party plugins.

And also (and perhaps most importantly): no custom script to test and maintain :)

[limonte]

@limonte Sorry can you tell me what this problem..

Line 27 in 742fc95

"uglify-js": "latest"

has to do with commitizen and semantic-release?

It has nothing to do with commitizen and semantic-release. Apparently, I was young and foolish year ago when I was depending on "latest" versions of devDeps.

Opened an issue for myself: https://github.com/sweetalert2/sweetalert2/issues/859

[toverux]

From "latest" and npm, to semver and yarn :smile:

[zenflow]

@toverux I'm now pretty sure this would be really helpful, but I still have a couple questions/concerns

We use squash-and-merge to merge PRs in Github (currently), so what happens when someone makes a PR with commits of different types, e.g. "fix(foo): Fix something" and "style(foo): Tidy up code style"? A squash-and-merge combines the commits into one commit with one message, so how do we deal with that?

[toverux]

As you can expect, you'll need to find a commit messages that describes the best what's been squash-and-merge'd.

So the canonical answer is to reduce to one commit message:

feat(foo): bar
fix(baz): qux
refactor(foo): quux

to:

feat(foo): corge

Those are the same because, here, the first three commits and the last are giving the same version number (if those three commits are pushed simultaneously). The first example does not reduces to 0.0.0 + 0.0.1 + 0.1.0 but 0.1.0.

So I'd say that most of the time, it's not a problem. If that becomes one, it may mean that the PR is too big and treats to many subjects.

[zenflow]

@toverux That makes sense. Thanks for the wisdom!

I set up semantic-release in sweetalert2-react-content, and I must say it feels pretty powerful, and I haven't even done any custom configuration yet!

[toverux]

Yep, I've already seen your PR, I'm watching the repo :)
I'm glad you like it!

[zenflow]

Yep, absolutely loving semantic-release for the fully automated release (as soon as a relevant change makes it to master), GitHub integrations (posts on issues & PRs when the change has been released), the CHANGELOG.md, and maybe more to come

I'm 100% in favor of using semantic-release in this repo too, but I would like to not use commitizen (or similar) in a precommit hook because:

1. We squash-and-merge our PRs, so (unless the PR only has a single commit) we have to write the standard commit message for the merge commit ourselves anyways.
2. I like to make temporary commits while I'm working, and then do some interactive rebasing later to pretty it up. If we had this repo configured this way, I'd have to first disable it in whatever branch i'm working in, and make sure it isn't included in a PR, and that would be cumbersome.
3. Some [potential] contributors might not be familiar with the standards for commit messages, and it would be a pain for them.

[zenflow]

Is anyone opposed to setting up semantic-release? @limonte @acupajoe @samturrell ?

[limonte]

My vote is totally for using semantic-release. So, it's possible to use it without commitizen? I thought semantic-release is based on properly formatted commit messages.

[zenflow]

I thought semantic-release is based on properly formatted commit messages.

It is, but we don't need commitizen to enforce that, especially since those commit messages often don't make it into master (the only place where it actually matters). In the case of a PR, there is often more than one commit, so the default commit message in Github is the title of the PR, which will most likely not be in the correct format, and so we will have to format the message ourselves anyways much of the time. It seems like for this reason (and the other above reasons) we should just not bother with commitizen, and instead rely only on writing the proper commit messages ourselves when we merge PRs.

[limonte]

we should just not bother with commitizen, and instead rely only on writing the proper commit messages ourselves when we merge PRs.

Sound good to me :+1: thanks for the explanation!

[zenflow]

If nobody does object to this, I think the first step will be finding (or building) a semantic-release plugin to handle committing the dist folder to the dist branch, i.e. keeping what our release.js script does for our Bower users.

[limonte]

semantic-release is taking care of SweetAlert2 releasing process now 🎉

KILL ALL HUMANS 🤖