Replace syncVersions by version grouping

[yjaaidi]

As quickly discussed with the lovely ngworker team @LayZeeDK, @NachoVazquez, @SerkanSipahi, and @santoshyadavdev, it appears that we need to provide a solution for project/package grouping by version.

E.g.: given a repo with 3 packages a, b & c, one should be able to sync versions for a & b but still keep independent versioning for c; meaning that changing a would have to bump b as well.

The tricky part is that the current approach either adds a "version" builder to the whole workspace (sync mode) or to projects individually (independent mode).

We can see the following alternatives:

• A: add options to the workspace builder

• A.1.: --projects option to construct the group

• A.2.: --path option (Suggested by ngworker team ;))
  This one is brilliant for the following reasons: a project can't be part of different groups, adding a project to a subfolder of the path will automatically add it to the group without changing the config. "Filesystem structure as config"
  Challenge with this approach: how to benefit from nx cache / dep graph. As the command would run on the workspace we can't enjoy something like nx run my-group-name version

• B: create a "group" project in workspace config like we already do in sync mode with a root path set to the the group folder. This way, Nx cache and Nx dep graph might work. I still wonder if it doesn't confuse Nx too much to have files which are part of different projects, i.e. the project and the group.
  This will just run the sync mode with a filter of projects that are in the group path. we also have to be careful about the root changelog.

It seems like the idea of folder grouping is the way to go. "B" is my personal favorite... if it works without hacks.

There are probably other solutions we didn't discuss yet. What do you think?

cc. @edbzn

[edbzn]

I'm also more in favor of B solution but I think it will make the workspace definition more complex than it is already.

What about keeping the workspace root project and add group definition here as the following :

{
  "name": "workspace",
  "root": ".",
  "architect": {
    "version": {
      "builder": "@jscutlery/semver:version",
      "options": { 
        "sync-groups": [
          { "name": "group-a", "packages": ["a", "b"] }, 
          { "name": "group-b", "packages": ["c", "d"] }
        ]
      },
    },
  },
}

The pro is the workspace definition still look the same as today with no more virtual projects added, the con is that we can't benefit Nx cache.

[LayZeeDK]

I also suggested simply an --exclude=project-c,project-x parameter for sync mode execution. This is similar to some of the nx ... commands.

[NachoVazquez]

But would that support more than one group?

[SerkanSipahi]

I would also favours this because it is known through the nx devs.

--exclude=project-c,project-x

[LayZeeDK]

But would that support more than one group?

Groups are certainly interesting. It's not a need we currently have though.

[LayZeeDK]

Consider --sync-exclude to prevent clashing with Nx' exclude option.

[LayZeeDK]

syncExclude could be defined in options of a target in workspace.json.

[yjaaidi]

An example of B could be something like:

{
  "name": "group-a",
  "root": "packages/group-a",
  "architect": {
    "version": {
      "builder": "@jscutlery/semver:version"
    },
  },
}

[LayZeeDK]

Yes, Option B suggests that instead of a single workspace project with a version target, we could use a grouping folder per sync group with an associated "project configuration" with a version target.

[yjaaidi]

nx run-many version --all

or

nx run group-a:version

[yjaaidi]

An example of ng-worker configuration could look something like this:

Project structure:

packages/
  angular/
    cdk
    material
    globalization  
  lumberjack
  spectacular

{
  "name": "lumberjack",
  "root": "packages/lumberjack",
  "architect": {
    "version": {
      "builder": "@jscutlery/semver:version"
    },
  },
},
{
  "name": "spectacular",
  "root": "packages/spectacular",
  "architect": {
    "version": {
      "builder": "@jscutlery/semver:version"
    },
  },
},
{
  "name": "angular-group",
  "root": "packages/angular",
  "architect": {
    "version": {
      "builder": "@jscutlery/semver:version"
    },
  },
},
{
  "name": "angular-cdk",
  "root": "packages/angular/cdk",
  "architect": {"build": "..."}
},
}

[LayZeeDK]

What happens if a project inside of a sync versioned grouping folder has a standalone version target?
A. Chaos! No one knows.
B. The standalone versioned project inside of the sync versioned grouping folder is excluded from the sync group.
C. An error is thrown, maybe asking the user to move the project outside of the sync grouping folder or remove its standalone version target.

[LayZeeDK]

ngworkers' use case is that in the ngworker monorepo, we would have:

• A standalone versioned project: Spectacular
• A standalone versioned project: Lumberjack
• A synced group of versioned packages following Angular's release cycle.

[LayZeeDK]

Tags for versioning:

Lumberjack: lumberjack-v3.0.0
Spectacular: spectacular-v1.0.0
Angular sync group: angular-group-v1.5.0 (or more likely: ngworker-v1.5.0)

[LayZeeDK]

Consider adding a tagPrefix/--tag-prefix option in case a grouping folder needs to be renamed--for whatever reason--without breaking the version tags