Feature request: Adding a lib from npm should not be a 5-step process.

[SethDavenport]

Please provide us with the following information:

1. OS? Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?)

Mac OS X (El Capitan)

1. Versions. Please run ng --version. If there's nothing outputted, please
   run in a Terminal:
   node --version
   And paste the result here.

angular-cli: 1.0.0-beta.5
node: 6.0.0
os: darwin x64

(node 6.0.0)

1. Repro steps. Was this an app that wasn't created using the CLI? What change did you
   do on your code? etc.

This is more of a feature request than a bug. However taking a look at this page in the docs https://github.com/angular/angular-cli/wiki/3rd-party-libs begs a question: why is integrating a lib from npm this complex?

In webpack it's just npm install --save foo (and maybe typings install --save foo). I understand that SystemJS requires a lot more config, which is one reason I have avoided it in the past.

However if we must go with SystemJS it would be nice to provide a wrapper command at least (e.g. ng install --save foo); adding 3rd-party deps is a common operation which other toolchains make fairly simple.

[nfantone]

What's the reason all of that boilerplate couldn't be automatically derived from package.json?

I mean,

1. vendorNpmFiles: ['moment/moment.js'] in angular-cli-build.js
2. 'moment': 'vendor/moment/moment.js' in system-config.ts

Can both be easily extracted and generated dinamically from package.json at build time.

[SethDavenport]

One advantage of SystemJS over Webpack is the ability to dynamically load modules in the browser, in dev mode.

Unfortunately async module loading is a feature I typically avoid. The large number of HTTP requests it produces makes it unsuitable for production; and the existence of source maps means that you can have a decent dev mode experience even with a single JS bundle created using commonJS at build-time.

So the main feature of SystemJS (or async module loaders in general) is something that I don't find very useful; this makes its extra layers of config on top of package.json even more troublesome.

That said I'm sure you have good reasons for doing it this way. Therefore something to automate the addition of npm modules would be appreciated if at all possible.

[TheLarkInn]

@SethDavenport webpack supports async module loading (not that you would need it for dev env), additionally it has webpack-dev-server that is a 2 line setup that has multiple varieties of sourcemaps available (depending on how fast you want your builds to run), and support incremental HMR, and watch.

[SethDavenport]

@TheLarkInn oh, I know :) I use webpack most of the time ... huge fan.

[filipesilva]

Yeah the 3rd party lib scenario isn't very friendly. As far as contrasting it with webpack, that discussion is underway on #909.

Regarding the boilerplate... a lot of config can't be derived, and even if it could not all installed npm packages should be added to SystemJS.

I'm leaving this issue open for people to pitch in suggestions on how the current 3rd party libs journey could be improved, but please let's keep the system vs webpack vs whatever out of it.

[nfantone]

Regarding the boilerplate... a lot of config can't be derived, and even if it could not all installed npm packages should be added to SystemJS.

Why not? What do we lose/gain? Trimming the final build?

Couldn't we solve this by adding a simple --yes-I-want-this-to-be-added-to-systemjs flag when installing with npm i in tandem with a "postinstall" script?

[filipesilva]

Trimming the final build is a concern, yes. The tree shaking might take care of it automatically though.

A postinstall script could maybe work, although I'm not sure of the technical details of making that work. For instance, how to get the installed package names, how to auto determine the module format.

Also it would require a custom flag on install or something similar, which is already deviating from how users would expect npm install to work.

[nfantone]

@filipesilva

Also it would require a custom flag on install or something similar, which is already deviating from how users would expect npm install to work.

Understood. But the only alternatives I can think of are actually worse: manually editing files or an entirely new CLI tool/command. Have you ever considered integrating jspm?

[filipesilva]

@nfantone we did at a time, but it suffered from a similar problem: you'd need to install packages using something other than npm. It'd configure systemjs for you, which was a plus, but wouldn't configure CLI stuff and there was no clear integration with ember-cli.

So at the time we didn't pursue it more. That is, of course, something that might change.

[nfantone]

Is dynamic module loading even a hard requirement? What about old school <script> tags? I'd go that way every time if it meant to keep using the tools we all know.