Investigate refactoring to use lerna publish

[jpnelson]

Advantages:

• code removal: we wouldn't need to iterate over packages, or even necessarily have pre/perform steps
• could remove the wonky git with gitHead in published packages. We'd just need a way to find the latest version so that we know which commits to analyse
• updated local dependency tree: lerna publish will update packages that depend on it to the latest versions.
• moving closer to lerna makes it fit better with the lerna ecosystem

Disadvantages:

• will be a bit of work, might make it a little bit unstable
• if we remove lerna-semantic-release pre / lerna-semantic-release perform that'd be a breaking API change
• using lerna more will make it harder to mock things in tests

How to get there:

• we'd need to make a PR to lerna to make publish pluggable, so that we could hook into it.
• we'd be able to reuse the semantic release adapters, particularly https://github.com/atlassian/lerna-semantic-release/tree/caribou/packages/lerna-semantic-release-analyze-commits
• we'd need a new way to figure out what the sha of the latest published version was, so we know which commits to analyse. There might be a way to achieve this with dist-tags

[joscha]

I am happy to give it a try if you think the current approach won't work for us over time. Would lerna publish leverage the logic of semantic-release to determine the next version?

[jpnelson]

Yes, I think we'd be able to keep the parts that analyse commit ranges. I'll set some time aside at some point to investigate this

[jan-molak]

That sounds like a good idea, did you guys have a chance to progress on this one?

[jpnelson]

Not much, I do still think it would be a nice thing to have though. In terms of features it'd be particularly useful to have an updated local dependency tree on publish.