semver
semver copied to clipboard
Can independent mode run over all libraries at once and produce single commit (not multiple)?
Guys, i'm sorry for be so bothersome 🙄
Sync mode update all changelogs and package.json versions at once (with one single version) and produce single "bump" commit. Indepdendent mode goes for each library and produce multiple "bump" commit for each library.
Is it possible to run independent mode like sync mode (over all apps and libs) and produce single commit not multiple?
Thank you!) 🍺
Hi @glebmachine, you're not bothersome, I like your suggestions! I think it's a complete valid scenario for a monorepo.
To make it work we should rework the versionProject
function which run standardVersion
internally and commit for each project. For now we can't influence on when and what's committed, so we should decompose standardVersion
into smaller functions to control the moment it commits.
What do you think @yjaaidi? It Seems to cross what you had in mind.
Hey y'all 😄 I have the same scenario as @glebmachine, would love to help if needed
Hey @EladBezalel! Happy to see you here 😊
Initially, we liked the idea of not reinventing the wheel and reusing the nx
's options like --projects
and --affected
.
Now, considering this issue + the grouping issue https://github.com/jscutlery/semver/issues/125, there is a common prerequisite: running semver once on the workspace with a global configuration.
Let's discuss this here first then you can go ahead with a PR or we can plan a call or a mob programming party 🎉
Current
The idea is to drop the current independent configuration which looks like this:
{
"name": "my-app",
"root": "apps/my-app",
"architect": {
"version": {
"builder": "@jscutlery/semver:version"
},
},
},
{
"name": "lib-core-a",
"root": "packages/core/a",
"architect": {
"version": {
"builder": "@jscutlery/semver:version"
},
},
},
{
"name": "lib-core-b",
"root": "packages/core/b",
"architect": {
"version": {
"builder": "@jscutlery/semver:version"
},
},
}
Goal
and to move to something like this:
{
"name": "workspace",
"root": ".",
"architect": {
"version": {
"builder": "@jscutlery/semver:version",
"options": {
"projects": ["lib-core-a", "lib-core-b"],
"groupBy": ["packages/core"]
}
},
},
}
-
projects
&groupBy
are optional - default behavior if
projects
is not set is to version all projects - default behavior if
groupBy
is not set is to version projects independently -
groupBy
allows us to sync packages versions (packages can only be grouped by path). Syncing all packages would meangroupBy: ['.']
The main advantage here is that we have one configuration for the whole workspace.
The challenge is to override the configuration for some projects, for example, when plugins will be available. We might want to give distinct plugins
for each project.
@edbzn what do you think?
As mentioned in #125, we'll be moving to a new configuration syntax that would look something like this:
{
"name": "workspace",
"root": ".",
"architect": {
"version": {
"builder": "@jscutlery/semver:version",
"options": {
"singleCommit": true,
"configs": [
{
"name": "rx-state",
"type": "independent"
},
{
"name": "cdk",
"type": "group",
"path": "packages/cdk",
"packages": [
"packages/cdk/operators",
"packages/cdk/helpers"
]
}
]
}
}
}
}
As you can see in this example, we could add a singleCommit
option to handle this feature.
hi guys, I'm looking forward to have this grouping or single commit feature, do you have a plan for it?
@daton89 Yes, we are planning to do the grouping soon, first, we are focusing on post targets (#317), it will come next. The single commit will come later because it needs a lot more work (related to #314).
Hi guys, is there any plan update on this request?
@davidren-apt This is the next thing I would like to work on BUT we need Nx to support workspace level executors before being able to introduce this change. So for now it's pending.
@edbzn since you have closed the issue in the Nx repo, could you give an update on how to use this now in combination with @jscutlery/semver
?
It's not doable in the current state, we need now to refactor the whole plugin, this will be hanlded in the next major release. We started to work on an RFC so it's in the pipeline.
Thank you very much for clarification. 🚀