Auto: Use npm as version source of truth

Oooh I like that. This might get tricky for monorepos though

Since we do --force-publish=* for lerna it shouldn't be an issue since all the packages should have a linked version.

In the future if we remove that flag we would have to... idk

Also we just run npm version which only takes a semver string. We don't actually set a package number anywhere right now. It wouldn't be to hard to set it ourselves but monorepos again seem like they would not be simple

Most of the commands work on tags too so if the release wasn't tagged that could cause some problems.

https://github.com/azu/can-npm-publish

"I’m increasingly convinced the “independent” versioning mode was a mistake. All it does is make people throw random packages into a single repository and then complain when they have to version them at the same time." ~ from lerna maintainer.

So --force-publish=* seems fine.

--force-publish and independent versioning aren't the same thing.
By default, lerna will only publish an update to a package if it's got changes to it, by using --force-publish=* we force lerna to publish a version of all packages even if there's no changes since the last publish.

i.e. package A has changes to it, B doesn't. lerna will only publish a new version of A (B will remain at it's current version). The next release A and B have changes, they'll both get published with the same new version.

Something I've been thinking about (and I'm not sure if this is ever a thing we'd support) is the potential for releases that aren't master (or the main branch). Up until this point, we've always assumed that there's 1 path for releases to take -- and they're always linear (using the latest version on npm or github).

What happens in the case of needing to patch a previous release? (1.x has a bug, master is on 2.x but you want to patch 1.x w/ a fix too) If we're going off of the lerna or pkg version I think we'd be okay. The PR lookups would calc a new semver bump and apply that to the version in the current branch.

If we change this to use something outside of the git tree I don't think we'd be able to support that behavior, as there's only ever 1 latest on npm (or wherever we fetch the latest version from)

That seems like a good feature. It may take some work to implement.

version:

• We calculate version using the latest release - could this easily switch to the package version?
• The latest release on github might be a problem. I don't think you can actually programmatically set the "Latest Release". So when publishing a patch to 1.x it would become the latest release.

release/changelog

• getCurrentVersion returns lastRelease if gt(lastRelease, lastVersion) - so this would need to be aware of that too

this means we are already using stuff outside the git tree, right?

We need to depend on latestRelease to be sure that it has a git tag associated with it, so switching isn't an option because we can't be sure that the latest npm version has a tag (like in the thing this issue describes).

I think that we would probably need a new flag that versions from the last git tag. --from-git

With that the release command would probably work. We would have to sort out what the changelog looks like.

the --from-git flag could also override looking at NPM for anything. I think that means we can merge #173