Publish to npm

[jasonkarns]

I would love to see this module on the npm registry (as would others: jasonkarns/bats-assert#5 (comment))

I'm the owner of the bats-assert module on npm. Since I consider this the spiritual successor to https://github.com/jasonkarns/bats-assert, I wouldn't mind officially deprecating my module on npm in favor of this one.

Assuming that we're 👍 on publishing to npm, I volunteer the bats-assert module name on npm. Which means we only need to bump this module to version 2.0 and publish.

[jasonkarns]

@ztombol any thoughts on this? I'd love to have bats-* published to npm so it could be added as devDeps without using github urls. If you are okay with it, I can begin.

[ztombol]

@jasonkarns Sorry for the hiatus. Due to personal reasons I had to drop everything a few month ago. I saw your numerous contributions over the past two months. Many thanks your hard work! I'll be gradually coming back to working on bats-* from this/next week. I'll get back to you soon! Thanks for the patience.

[ztombol]

@jasonkarns I'm guessing your npm package used symantic versioning and bumping to 2.0.0 is necessary to signal that we are breaking backward compatibility.

Leaving 0.x.y means every change that is non-backward compatible will result in a major number bump. Though I don't think there will be too many changes like that, to minimise noise, I suggest we go ahead with this plan after #14 and #15 have been merged. What do you think?

[jasonkarns]

The reason I think we should bump to 2.0 is because my package is already at 1.1.1, and my bats-assert and yours aren't really compatible in any significant way.

Bumping this bats-assert to 2.0 when publishing would be (from the perspective of a user of my existing bats-assert) as if we just did a rewrite and significant API change. Which is close to the truth.

We can't publish to npm as anything less than 1.1.1 because that would result in interleaved versions. The versions I have published on npm are 1.0.0, 1.0.1, 1.1.0 and 1.1.1. The versions of this bats-assert are 0.1.0, 0.2.0 and 0.3.0. Which implies that your version "preceded" mine, in terms of releases.

If we were to keep the current versions, then it would be quite odd for the package to be at 1.1.1 and suddenly have newer releases that have older version numbers. And further, when this package becomes ready for a 1.0.0 release, we'd have to skip over it to something greater than 1.1.1. (Version tags on npm are immutable, so the 1.0.0 - 1.1.1 tags are locked)

That's why I suggested just releasing as 2.0. It keeps releases of this bats-assert fully after my releases, and avoids any interleaving of version numbers. semver implications are a huge bonus.

[jasonkarns]

Also, I'm fine with holding off till 14 and 15 are merged as you suggested.

[ztombol]

Okay, got it. Thanks for the detailed answer. Then, let's work out those pull requests first.

[jasonkarns]

#14 and #15 have both been resolved in my fork as of 2.0.0

That release has been published to npm as v2.0.0: https://www.npmjs.com/package/bats-assert