Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Improvement of conventional commit messages #53
Hello, (yes, me again)
I've done a bit of a search;
Because of the way things are going we're moving away from the monorepo approach and having things separate to make it easier for publishing and building.
I'd like to request some enhancements. (Unless they're already in place and I'm missing them again)
Greenkeeper differentiates between dependancies & devDependancies. deps get a fix: and devDeps get a chore. The fix triggers a release. This is perfect for our a lot of our packages and in theory how we'll be building products. At least how I see it happening in my head any way. It would be nice if dependabot had a config to do something similar?
I might be able to jig things with commit-analyzer if dependabot was doing a conventional message ... but it might end up being a bit messy.
There is a lot of love for dependabot at wmfs though and the support for Docker will come in handy very soon!
Thanks for the feedback!
On conventional commits, it looks like it was just a case of Dependabot recognising that your repo had switched over. I can see that wmfs/food-hygiene-blueprint#8 uses angular style.
On scoping, what's your use case for it? I removed it a few months ago because Angular themselves don't use it for package upgrades (Angular commits here).
On differentiating between deps and devDeps, I can see where you're coming from, but are you sure you want t release each time one of your deps gets a patch / minor release? If you're not pinning your dependencies, which for a library you probably shouldn't be (to increase the number of dependencies that can be shared by those downloading it), then a release isn't really necessary I don't think? It also feels a bit weird to mark performance enhancements in sub-dependencies as a
I think the way Greenkeeper does it works well. I think for runtime deps they do a
I know configuration is kind of a last resort, but maybe a configurable prefix would be good?
Just to throw a wrench in things here, I'm working on a new project https://github.com/electron/algolia-indices which should ideally be (semantically) released when any dep is updated, regardless of whether it's a runtime dep or a dev dep.
Okay that makes sense, I've removed the old monorepo and setting up the new repos individually now.
It's just a nice thing isn't it really. We're trying to get into the habit of writing better commits and making this easier to read.
-----> edited the below
Right bare with me here, (@jezhiggins could probably explain better than I can) but basically Tymly is very modular in it's make up, with plugins and blueprints and a core Tymly at it's heart. The plugins in particular use Tymly for testing. Blueprints have plugins as dependancies. It's like a web but not really a web.
The tymly-core product, which is arranged in the way you'd normally expect - package at the top with a tree of packages underneath it.
We then have a whole array of plugins to that product. They don't have a dependency on the core, they have a devDependency because it's used in the their tests. Any change in the core, even a minor fix, could have implications on the plugins. Therefore, any time one of those core packages changes, we want to re-release the plugins so that we can say "this plugin version X has been verified against core version Y".
I'm not starting to think the initial title of the request should be different.
This may interest you as well @zeke
I've just had a go with commit-analyzer plugin and it's worked rather nicely and simply as well.
So when dependabot comes a long with a commit and it's merged the commit message having 'build:' will trigger a minor release. Party time!
If dependencies and devDependancies were differentiated by Dependabot? Similar to Greenkeeper, then we could use the plugin to give devDependancies a patch release etc if it's updated as a chore for example.
But Dependabot (when we pay for the private repo access
So with the greater control of bumping we'd be able to define specific builds for show and tells or tested by customers then they only get bumped and build at specific days of the week.
Interesting. I can see an argument for using the
What I don't like is changing the commit type itself to
How about we add in scopes, and go for