Moved from https://github.com/intuit/auto-release/issues/176
@aleclarson said:
Here's a plugin I need right away:
It scans the commit messages of a PR for
semantic-releasestyle prefixes (eg:fix:,feat:,BREAKING) and automatically applies the appropriatepatch/minor/majorlabel to the PR.
Inspired by this Twitter thread.Would you consider this as an officially supported plugin?
@hipstersmoothie said:
Yeah that sounds like a good plugin! I'm okay with it being official. All though we might need to add an extra hook or two for this behavior
A hook with the name
parseCommitcould enable this here
@aleclarson said:
We could use parse-commit-message to extract metadata from commits (though its dependency on esm makes it a little heavy, but that will be removed once NodeJS supports ES modules natively). In the meantime, we could fork it and remove the
esmdependency if it bothers us enough. Even if we don't fork, it's still ~6x smaller than whatsemantic-releaseuses.
That's pretty weird how it depends on ESM
It should probably be using esm for the build and not in production
its kinda like using babel-register instead of just building it and publishing the dist folder
I thought the same at first, but a look at the source code says otherwise.
edit: Oh nvm, you're saying esm can be used to compile before publishing. We should send a PR.
It looks like a good module otherwise. Nice and lean
Looks like esm isn't made for compilation: https://github.com/standard-things/esm/issues/13#issuecomment-321710199
I say we fork for now, and convert the import and export syntax to CommonJS.
hmm yeah i was just reading the readme. Looks like i misunderstood
esm seems to add 65kb 馃槷
https://packagephobia.now.sh/result?p=parse-commit-message
https://bundlephobia.com/[email protected]
I'll make a pr to switch to https://github.com/developit/microbundle and maybe he will add it.
You should consider using https://github.com/egoist/bili instead. It has half the install size, but it may have other tradeoffs. Not sure.
Btw, to join the party. git-commits-since and detect-next-version might be more helpful here?
I'm using esm because of guarantees and because it's behind the Node's esm feature flag. I easliy could used ascjs or similar like rewrite-imports, but esm supports a lot more than just the import/exports. And because I didn't won't _any_ build step or anything, for testing I just use it as a hook to my runner.
Which brings us to that, we can switch to ascjs or asbundle.
@aleclarson why the size I so much of a problem? Even in node land, our package managers are already smart enough to dedupe.
@aleclarson why the size I so much of a problem? Even in node land, our package managers are already smart enough to dedupe.
I never mentioned duplicate dependencies as a concern. I'm just wary of bloated tools in general. "The lighter the better" is my rule of thumb, but to each his own. I'm not really interested in debating this. :)
Btw, to join the party.
git-commits-sinceanddetect-next-versionmight be more helpful here?
I'd prefer using parse-commit-message since those packages seem to duplicate logic that already exists in auto-release, but maybe @hipstersmoothie would be up for replacing the existing logic with those packages to reduce burden of maintenance.
:rocket: Issue was released in 10.0.0 :rocket:
Most helpful comment
I never mentioned duplicate dependencies as a concern. I'm just wary of bloated tools in general. "The lighter the better" is my rule of thumb, but to each his own. I'm not really interested in debating this. :)
I'd prefer using
parse-commit-messagesince those packages seem to duplicate logic that already exists inauto-release, but maybe @hipstersmoothie would be up for replacing the existing logic with those packages to reduce burden of maintenance.