This requires a field similar to peerDependencies, but those are required by Node, so only looked at by the update schematics. So something like optionalPeerDependencies that is read by ng update, and if the dependency is there treat it as a peer deps, otherwise ignore the field.
This is useful because we want ng update @angular/cli to update build-angular and other packages automatically, but still let the user remove them from their projects if they’re not needed (so not directly depend on them). Same for angular.
Solution A: add a new dependencies to the ng-update field in package.json. This has similar semantics to dependencies in the root package.json object, but would be only used by ng update itself.
Solution B (recommended): Considering we already support packageGroup, I suggest reusing it instead. Right now, the packageGroup field in the ng-update field in the package.json is typed string[] and does not support setting different versions of it. Reusing that field to type it string[] | { [name: string]: string } where the value is a version range (similar to dependencies) would fix this the right way, while keeping backward compatibility AND keeping the change scoped to ng-update itself.
The second solution would take less than a day to build, test and release.
Please discuss.
This requires a field similar to
peerDependencies, but those are required by Node, so only looked at by the update schematics. So something likeoptionalPeerDependenciesthat is read by ng update, and if the dependency is there treat it as a peer deps, otherwise ignore the field.This is useful because we want
ng update @angular/clito update build-angular and other packages automatically, but still let the user remove them from their projects if they’re not needed (so not directly depend on them). Same for angular.Solution A: add a new
dependenciesto theng-updatefield in package.json. This has similar semantics todependenciesin the root package.json object, but would be only used by ng update itself.Solution B (recommended): Considering we already support
packageGroup, I suggest reusing it instead. Right now, thepackageGroupfield in theng-updatefield in thepackage.jsonis typedstring[]and does not support setting different versions of it. Reusing that field to type itstring[] | { [name: string]: string }where the value is a version range (similar to dependencies) would fix this the right way, while keeping backward compatibility AND keeping the change scoped to ng-update itself.The second solution would take less than a day to build, test and release.
Please discuss.