-
Notifications
You must be signed in to change notification settings - Fork 133
migrate away from bower #488
Comments
I'm against this issue since it would mean we would have to refactor so many things and take care of any other possible issues. This is a big change and should only be take care of if highly requested. As for now, I wouldn't touch it at all. |
I'm thinking the same way @lordgreg does. I am fearing too big of a change from one generator release to another. And btw. what does yeoman has to do with bower? We load yeoman over npm, don't we? |
The part that could possibly impact the experience of the generator is that yeoman runs bower automatically for you after project generation. If they drop the support you'd have to run it separately. Just a minor inconvenience, though. But you make valid arguments, it's probably a big change, or is it? However, I think it's good to stay on top of it and see how bower is supported in the long run. Moving to npm yields some advantages two, on the other hand. You don't have to have bower installed as a separate dependency. |
Yeah, this only happens for project setup, this happens to only a few devs sometimes a year so I'll be ok with that.
I think all the 'auto-injecting' and stuff will be different and can therefore be a lot work to do.
True, but I think angular1 is still 'just inject the script into |
While I was investigating for our yarn integration #469 I stumbled across these two statements, that should motivate us to move away from bower in the long run. It looks like its yeoman support is going to be deprecated in a not so distant future.
@lordgreg, @MathiasTim. What do you think?
The text was updated successfully, but these errors were encountered: