Angular-cli: Proposal: support for bower packages

[nosachamos]

Currently, angular cli relies entirely on npm for package management. While this is fine in many cases, bower is still widely used. Unfortunately, there is no good solution for using bower-managed packages with the cli.

A workaround mentioned in a different issue suggests configuring the .bowerrc file to move the bower_components folder into the public folder, as its content is then copied to the dist folder. This works for development, but obviously not in production. You definitely don't want the whole bower_components in your production build, but instead just pick the css and js so they can be bundled, minified, etc and then injected into your index.html

I know this has been brought up a few times, but still, none of the workarounds presented before are really solutions for a real product where vendor js files and css need to be bundled, rev'ed, minifed, etc.

A few reasons to consider supporting it:

• Many packages are only available on bower;
• Bower is still a very popular frontend package manager, proven to work well;
• It's no doubt the simpler solution when it comes to managing conflicting versions of dependencies and packages (a big deal in the frontend);
• Ember cli is a huge success, entirely based on bower. Which shows bower alone could take care of the frontend dev dependencies. Npm is cool, but full of issues when it comes to frontend yet to be resolved (as elaborated here http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging).

IMHO skipping bower and relying entirely on npm is not a good move. NPM may become the best package manager for the frontend, but as of right now, for many workflows bower is still needed.

BTW, ng help lists bower support for the new and init commands:

  --skip-bower (Boolean) (Default: false)
    aliases: -sb

Having it not be skipped on ng new and ng init would be fantastic!

[hacknaked]

I personally wouldn't recommend Bower in 2016.

• https://medium.com/@nickheiner/why-my-team-uses-npm-instead-of-bower-eecfe1b9afcb#.pf63cftxp
• https://www.quora.com/Why-use-Bower-when-there-is-npm
• https://gofore.com/stop-using-bower/

Bower vs NPM (source http://www.modulecounts.com/)

[nosachamos]

While some of the points made in the blog posts are valid (such as human interaction during conflict resolution, etc), the number of modules is hardly one of them. I'm not waging war against npm. Instead, I'm bringing up that a popular, functional and very easy to use package manager is well supported by other successful CLIs, and lots of people still use them (and there is no reason to think they should or will stop, if it's working for them), so it wouldn't hurt supporting it on the new angular CLI.

Bower's package count continues to grow, as evidenced above, and virtually all modules packages for the frontend. NPM modules are becoming more and more popular, but a big part of the modules there are for node, not frontend. Also, older (that lots of people still need) and many new libraries are only on Bower.

It'd be pointless to list the issues with npm as a frontend package manager (whenever a package is available for both, it's really a matter of personal preference whether one goes with npm or Bower).

I guess the key is to keep in mind I'm not suggesting to drop npm, or that Bower is better, or anything like that . The idea is to add support for Bower instead, for the reasons listed above.

[hacknaked]

but as of right now, for many workflows bower is still needed.

@nosachamos Can you please clarify which are those workflows where bower is still needed or a better solution than, for example, npm+browserify?

[nosachamos]

Like I said, its not Bower versus the other tools. I'm not saying its
better. I'm saying its popular, practical, widely used, other clis were
very successful supporting it and it wouldn't hurt supporting it here as
well. For teams and developers that like bower and use it, this is a
barrier for starting with the new angular cli.

[trimeyko]

Vote for bower support, some of modules required exists only as bower packages, so this would be nice at least as some turned off by default option.

[basudebpal]

I think adding support for Bower will help the developers in front end dependency management in a better way.I personally prefer Bower over npm for front end. Also those developers who would want to keep back end and front end coding/dependency management separate/independent from one another(I am one of them :) ) would benefit. Also, this means that angular2 packages would have to be managed using Bower.

[softdays]

Considering the need of sharing components in non-public context, it is much easier to set up a private bower register than a private npm registry.

[ciesielskico]

I need bower support since google-chart is only available on bower, not npm.

https://github.com/GoogleWebComponents/google-chart/blob/master/bower.json
https://googlewebcomponents.github.io/google-chart/components/google-chart/

[vmilitello]

As said before, create a bower register is way easier than create an npm registry. Besides, migrating old app from angular 1 to angular 2 is already painful without the need of add more complexity such replacing bower libraries with the npm version of them (when they exist).

[delasteve]

Can be done now with the scripts and styles arrays in angular-cli.json file.

[hansl]

Closing this; we will not directly support bower, we just won't do anything to block it. You can definitely make it work with a tutorial and webpack.

[angular-automatic-lock-bot[bot]]

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._}