Use peerDependencies

[Airblader]

Would it be possible to switch from using dependencies to peerDependencies? The dependency graph for schematics-utilities is pretty big: http://npm.broofa.com/?q=schematics-utilities@2.0.1

[nitayneeman]

Hey,

This was considered in the past and might be implemented in the next major version (when the library will be aligned to @schematics/angular v10.x).

By the way, what's the version of @schematics/angular you're working with?

[Airblader]

This […] might be implemented in the next major version

Awesome, thanks!

By the way, what's the version of @schematics/angular you're working with?

Currently ^1.1.2 since I hadn't tracked this repository and had no need to change anything. I'll have to look into changes in 2.x and upgrading.

However, on my side I need to even consider splitting the schematics-utilities usage into a separate package. I used it to have ng add support, but it being in the same package means the user ends up installing all of schematics-utilities' dependencies (which is ~180) for something that was only needed at the point of ng add.

[nitayneeman]

This […] might be implemented in the next major version

Awesome, thanks!

By the way, what's the version of @schematics/angular you're working with?

Currently ^1.1.2 since I hadn't tracked this repository and had no need to change anything. I'll have to look into changes in 2.x and upgrading.

However, on my side I need to even consider splitting the schematics-utilities usage into a separate package. I used it to have ng add support, but it being in the same package means the user ends up installing all of schematics-utilities' dependencies (which is ~180) for something that was only needed at the point of ng add.

I believe that many still use this package for the ng add support - so somehow the core schematics packages should be installed either way in order to allow it. Maybe do you have a suggestion on how to keep this support while reducing the dependency size?

peerDependencies is an option, but this means that extra steps will be needed (installing the core packages) assuming you want the ng add support.

Another option is splitting this package to something like "core utilities" and extras so that the core would be slim as possible (and could apply the peerDependencies approach as well BTW).

A completely different way is cleaning up the packages after ng add finishes, but this sounds problematic when we actually do want these packages.

[Airblader]

Another option is to do it on "my" side, i.e. say I provide some library @foo/lib. Instead of ng add @foo/lib I could provide a meta package to do ng add @foo/install which then installs @foo/lib. Since schematics-utilities would only be used by @foo/install, it would not end up permanently installed in the target project.

In theory @foo/lib could also have schematics-utilities as a peerDependency such that the project can afterwards uninstall it again. But this would turn the nice ng add @foo/lib into yarn add schematics-utilities; ng add @foo/lib; yarn remove schematics-utilities :-(