Repository navigation
Feature request: Adding a lib from npm should not be a 5-step process. #882
Description
Please provide us with the following information:
- OS? Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?)
Mac OS X (El Capitan)
- 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)
- 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.
Activity
nfantone commentedon May 23, 2016
What's the reason all of that boilerplate couldn't be automatically derived from
package.json?I mean,
vendorNpmFiles: ['moment/moment.js']inangular-cli-build.js'moment': 'vendor/moment/moment.js'insystem-config.tsCan both be easily extracted and generated dinamically from
package.jsonat build time.SethDavenport commentedon May 23, 2016
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 commentedon May 25, 2016
@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 commentedon May 25, 2016
@TheLarkInn oh, I know :) I use webpack most of the time ... huge fan.
filipesilva commentedon Jun 2, 2016
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 commentedon Jun 2, 2016
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-systemjsflag when installing withnpm iin tandem with a"postinstall"script?filipesilva commentedon Jun 3, 2016
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 installto work.nfantone commentedon Jun 6, 2016
@filipesilva
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 commentedon Jun 7, 2016
@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 configuresystemjsfor you, which was a plus, but wouldn't configure CLI stuff and there was no clear integration withember-cli.So at the time we didn't pursue it more. That is, of course, something that might change.
nfantone commentedon Jun 7, 2016
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.TheLarkInn commentedon Jun 7, 2016
We want to make it a seamless process for people to use. Therefore when somone does
ng install some-libwe need to do the following:Maybes:
nfantone commentedon Jun 7, 2016
@TheLarkInn I'd like to refer you to #845 (comment).
typings.Remaining things are CLI-related. We should find a way to get rid or work around those. Why do need yet another tool?
12 remaining items
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
angular-automatic-lock-bot commentedon Sep 5, 2019
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.