Open Airblader opened 4 years ago
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?
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
.
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 ofng 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.
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
:-(
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