Add group for @angular/cli

[just-jeb]

Angular CLI is an integral part of Angular ecosystem but Angular can be used without it as well.
However, each Angular CLI release consists of multiple packages (monorepo, just like Angular) and therefore these packages should be grouped in greenkeeper in a separate group.
Currently every project that depends on one of the packages from @angular-devkit scope will break upon every release.
Here is an example for that (having this issue every time).

[Koslun]

@meltedspark I believe this grouping will not work with Greenkeeper as it is today because at least some of those dependencies have wildly different versions. This is stated in their docs:

Note that we only support monorepo releases in which all modules contained in a single release have the same version number, this is what Lerna calls Fixed or Locked Mode, which is their default.

If it really is breaking that much with some combination of those dependencies I guess I would make sense to put it into this fixed or locked mode, like both the regular Angular and Angular Material releases.

[just-jeb]

Unfortunately making such a change is not up to me since I'm not one of the Angular CLI maintainers.
Hope the greenkeeper team will deal with this limitation soon, otherwise I won't have other choise than changing to a different solution.

[Koslun]

@meltedspark yeah I think the only options you have are:

1. Create an issue in this or the main greenkeeper repo for specific functionality changes that would allow you to more easily track this.

or

2. Create an issue in the Angular CLI repo regarding the difficulty in managing these versions and urging them to change some or all of their packages to use a fixed or locked mode. Given that both the Angular core libraries and the Angular Material libraries already work like this I think it might make sense for them to make this change. Otherwise you can probably get an answer for why they've chosen to have their current different versions.

[travi]

This is stated in their docs

i'm curious if someone from the greenkeeper team could confirm if this is still the case or if the docs need to be updated. i would think that this change on the greenkeeper side of things would take care of the independent versioning.

Create an issue in the Angular CLI repo regarding the difficulty in managing these versions and urging them to change some or all of their packages to use a fixed or locked mode.

please don't go this route. as a package consumer, fixed/locked mode is my biggest complaint about projects moving to monorepos. while it may make things simpler for maintainers, it removes all of the information that semantic versions are intended to convey to consumers when packages change independently. fixed/locked mode just pushes the complexity to consumers by forcing them to update everything every time even a small change is needed in a single package.

[Koslun]

@travi

i'm curious if someone from the greenkeeper team could confirm if this is still the case or if the docs need to be updated. i would think that this change on the greenkeeper side of things would take care of the independent versioning.

Agree on both counts, though I'm not completely sure about if the commit solves this case or not.

please don't go this route. as a package consumer, fixed/locked mode is my biggest complaint about projects moving to monorepos. while it may make things simpler for maintainers, it removes all of the information that semantic versions are intended to convey to consumers when packages change independently. fixed/locked mode just pushes the complexity to consumers by forcing them to update everything every time even a small change is needed in a single package.

Kinda disagree with this for this case and for the general case for when many libraries are very interconnected. Locking versions means that all the packages locked together can take advantage of any new API features contained in those locked packages without having to change which dependency they depend on, which in turn would arguably cause a major version bump to the dependency.

It also makes it very ambiguous and requires a bit of an investigation to find out which dependencies fit with each other, if you are not simply on the latest for each package.

So the more connected your packages are and the greater number of such connections you have, the greater effort I see is also placed on the consumers of said dependencies to keep track of which package versions go with which. And so I definitely think Angular with it's like ~10 packages does well in having locked releases to the packages in the main public Angular monorepo.

With 9 packages being in the @angular-devkit scope alone I think there's very likely a case for having locked versioning for at least some of the Angular CLI packages.

That said, I'm not really even sure how many consume those specific packages as you can use the Angular CLI without it. Also have not looked very closely at exactly how all of these relate to each other and at what state each package is in.

Regardless, putting the issue in there will not guarantee it's implementation in any stretch of the imagination, might only make someone in the team consider it. At which point it might be implemented or that they have some good reason for not going with this.

[travi]

for more evidence that the docs are out of date, i added gatsby to the monorepo definitions recently, and they do not use locked mode. this PR shows that greenkeeper can still handle the various versions that were released at the same time.

[ljharb]

enzyme does not use locked mode (and i would find it horrific to do so), and it's been present in these monorepo definitions nearly from the day the feature was released to the public.

[travi]

i sent a PR to get the docs up to date.

@ljharb thanks for mentioning that. also, as a consumer, i want to say thank you for following that approach since it does communicate the impact of the changes to each package far better than locked mode would.

[just-jeb]

Thanks everybody for participating. I suppose now we should patiently wait for the approval.

[Koslun]

Looking at Angular-cli more closely I think they already have two different groups of locked releases. One on version 7.1.x and another at 0.11.x. Where they've updated both simultaneously in at least the last two releases. This also shows that the grouping in this PR matches what happens at Angular-cli: release commit.

With GreenKeeper supporting different versions it shouldn't matter then that there are two groups either.

@ljharb

enzyme does not use locked mode (and i would find it horrific to do so) ....
Don't want to derail this thread anymore as Angular CLI kind of do use locked releases either way, but curious on why "horrific"? Would you go as far as saying that it really applies to all scenarios of using locked releases being simply "horrific"?

I figure that locked releases lend themselves much more to a scheduled release cycle like Angular and to some degree Angular-cli with about one every week. In which you will often get an update in each package every release. Where I think such schedules further lend themselves to projects which can place developers to work on them as their regular 9 to 5 job.

Even with the premise of it only benefitting the maintainers, as stated by @travi, I think that I as a consumer would in general prefer the maintainer spending as little time maintaining legacy version compatibility and as much time simply focusing on developing new features.

[just-jeb]

Any update?