Skip to content
This repository has been archived by the owner on Jul 8, 2020. It is now read-only.

migrate away from bower #488

Open
gruppjo opened this issue Feb 15, 2017 · 4 comments
Open

migrate away from bower #488

gruppjo opened this issue Feb 15, 2017 · 4 comments

Comments

@gruppjo
Copy link
Contributor

gruppjo commented Feb 15, 2017

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?

@lordgreg
Copy link
Contributor

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.

@MathiasTim
Copy link
Contributor

I'm thinking the same way @lordgreg does.
Also I'm not 100% sure, that the authors of the posts you mentioned are aware, that yarn does no more support bower.
https://bower.io/blog/2016/using-bower-with-yarn/

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?

@gruppjo
Copy link
Contributor Author

gruppjo commented Feb 17, 2017

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.

@MathiasTim
Copy link
Contributor

MathiasTim commented Feb 17, 2017

If they drop the support you'd have to run it separately. Just a minor inconvenience, though.

Yeah, this only happens for project setup, this happens to only a few devs sometimes a year so I'll be ok with that.

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.

I think all the 'auto-injecting' and stuff will be different and can therefore be a lot work to do.

Moving to npm yields some advantages two, on the other hand. You don't have to have bower installed as a separate dependency.

True, but I think angular1 is still 'just inject the script into index.html'. And with npm you need to think about version conflicts, since bower is doing the resolutions and npm afaik doesn't, they just nest it. (flat vs nested dependency tree)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants