Inflated dependency tree when using ngxtension

[Kaemmelot]

Please reduce the required (production) dependencies of ngxtension. (This is somehow related to #156)

Reason:
Currently ngxtension requires nx, @nx/devkit and ts-morph as production dependencies. These packages are enormous and blow up the transitive dependencies in projects using ngxtension. Also, because of this, security scans (like Blackduck) currently see Nx and its dependencies as production code, which causes problems in our use case.
I cannot see a reason why these dependencies cannot be declared as devDependencies instead.

Thanks for this great library!

[nartc]

Hi Kaemmelot,

The reason why nx, @nx/devkit, and ts-morph is dependencies instead of devDependencies is because of ng add. Now, this assumption was based on my experience with the package managers' behavior from before (they do not install devDependencies by default) but I think they change now. I can take a look.

[Kaemmelot]

This seems to be a bigger problem than I initially realized. I have been experimenting with this over the last few days and I now assume that there is a structural problem with the package managers or the concept of migrations included within a library in general.

First of all, nx does not seem to be used by the schematics/migrations, neither for Angular CLI nor for Nx. @nx/devkit and ts-morph are in fact required for these schematics/migrations to work.
In NPM it seems to be impossible to provide a package that can be partially used in production and development at the same time. At least when the dependencies differ.

I think there are a few unfavorable ways to handle such cases:

• Add devopment dependencies to dependencies or peerDependencies and depend on tree shaking to get rid of them in production (as currently done for ngxtension)
• Provide two separate packages, one for development and one for production (one could argue about separation of concerns here)
• Bundle required development dependencies with bundleDependencies into the package (destroys all package management benefits)
• Maybe it would be possible to use peerDependencies with an optional flag in their meta data and tell the library users to install these dependencies later on if needed (does not work with Angular schematics/Nx migrations)

I guess what would be really needed here is either peerDevDependencies or an additional dev flag in peerDependenciesMeta to provide transitive development dependencies.

Not sure what the best course of action would be in this case.