changedPackages relies on specific commit format

[anilanar]

Although commit is a plugin, changedPackages in northbrook core relies on a commit format implied by the commit plugin.

I think Lerna's way of detecting changed packages is more generic: It executes git diff ${lastTag} -- ${pkg.path}. If there's a diff, then that package is changed.

What do you think?

I propose moving old changedPackages into a plugin, and explicitly document/mark dependencies between plugins (i.e. release heavily depends on commit).

---

My use case is as follows:

• I use a custom commit format for which I have an existing changelog generator etc.
• Create a plugin that will iterate changed packages and update their versions based on a questionnaire and on some internal/personal heuristics.
• Create a plugin that
• Create a plugin that will iterate changed packages, compare their package.json version with npm version, and execute npm publish if necessary.

1) northbrook bump-versions
2) ./bin/update-changelog.sh
3) user does a git diff, to check if everything is as he wishes
4) git add packages/*/package.json CHANGELOG.md
5) git commit -m "bump versions and update changelog"
6) git tag ${version user chose in bump-versions}
7) northbrook publish-changed

Later on, I can potentially merge 1-7 into a single plugin/script.

[TylorS]

Yeah, I agree that there can and should be a better way to watch for package changes and there are a lot of dependencies on commits. This was originally done for 2 reasons; based on my experiences and beliefs so far.

1. Commit messages are super important, but also usually done very poor. I want to force good standards where I can, and commits is one of them.
2. I want releasing to be 100% automated, there should be 0 user intervention, and using commit message with a particular format was the best way I could think to do that.

I'm very open to better ways to manage this. I've thought about combining git diff ${lastTag} -- ${pkg.path} and some querying of NPM to do some parts of this better, but it still leaves out the automatic versioning. For example semantic-release also works in precisely the same way, and Northbrook's approach is actually heavily based on my experience with lerna-semantic-release.

[anilanar]

I agree. However I think conventions/methodologies should go into plugins (and it's fine if they are default plugins shipped with northbrook) as there are usually multiple ways of doing things right.

I think northbrook core should try its best to convey useful information that all plugins can benefit from. For example depGraph is one of them. Changed packages since last release, all affected packages based on changed packages (through dependencies among them) all sound useful without enfocing any opinions, except git tags. I'll give this a further thinking though.