-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider dropping support for bower #59
Comments
+1 for dropping. If rave focuses on npm and having really good experience there - we might Bower support has been dragging this project down since day one. There are Lately, the bower folks seem to be rallying around legacy global script The lack of education about modular architectures is a problem for us. The In addition, they're debating an alternative to "moduleType" [4]. In short, Now they're dropping the "version" property and making the "name" property There are, of course, counter-arguments. As @KidkArolis Am I just being cranky and stubborn? Should we embrace bower's loose nature Thoughts? [1] bclozel/gulp-bower-src#5 — |
+1 I feel bower support has been and will continue to be a time sink, and it has taken time away from other important things, like build support. I agree w/ @KidkArolis that it would be better to provide an amazing end-to-end experience for 1 package manager, npm, and keep an eye on where bower goes to see if we can target it later. We'll undoubtedly run into situations where a rave user is tied to bower for whatever reason. We'll need to have good answers for those situations. |
It seems that the changes made in the 0.3.x versions have inadvertently fixed all known (and fixable) bower issues. As a result, I haven't experienced any bower-related problems while helping others build rave-based apps over the past several weeks. I know that there are still bower-related issues, though, since there are many bower packages that have incorrect metadata. Most of these "broken packages" provide global scripts, rather than modules, which likely explains why I haven't seen any issues. (yuk, global scripts) 😿 As far as dragging this project down, I'm not sure if bower is a problem for us any more. How are you guys feeling about this lately? |
With all the new changes coming to npm, I feel like it is going to become the perfect package manager for browser/node/js in general. Drop bower and support something that has a much better track record. |
I recently switched a project from bower to npm at work, and all i had to Its cool bower is currently supported. I personally consider bower somewhat harmful..
|
As a complete newcomer to modern JS development, if npm can be made to do the stuff that bower is generally used for, I'd find it much more comprehensible to have a single package manager. |
I think that pretty much describes how I feel as well. Supporting bower has already proven to be a big time sink. As long as simply retaining the current level of support doesn't also become a time sink, it makes benefits of rave available to a wider audience. |
This is pretty much how I feel, as well. I don't mind spending a bit of time here and there, but if bower support becomes problematic again, we'll have to let it go, imho. Also: I think we'll need to revisit this decision before releasing 1.0. I am closing this issue for now, but -- as usual -- comments are always welcome. |
Bower support has been dragging this project down since day one. There are way too many ambiguities and uncertainties, imho. Most of the issues in this repo are to fix bower-related problems.
Lately, the bower folks seem to be rallying around legacy global script architectures. The gulp folks seem to be reinforcing this [1] [2]. The "moduleType" property that was added to the bower CLI has still not been added to the spec [3].
The lack of education about modular architectures is a problem for us. The less users know about modules, the less they'll understand how to use rave.
In addition, they're debating an alternative to "moduleType" [4]. In short, the specs are still flailing.
Now they're dropping the "version" property and making the "name" property optional [5]. Without these, the code will be more complex and we'll have to guess or default the values.
There are, of course, counter-arguments. As @KidkArolis has often mentioned, we should be relying less on configuration metadata and more on auto-detection, anyways. Furthermore, every time I complain about increasingly unreliable bower metadata, @briancavalier thinks of defaults and assumptions that account for reasonably common conventions.
Am I just being cranky and stubborn? Should we embrace bower's loose nature and call it a blessing in disguise?
Thoughts?
[1] bclozel/gulp-bower-src#5
[2] https://github.com/ck86/main-bower-files
[3] bower/spec#10
[4] bower/spec#23
[5] bower/spec#22
The text was updated successfully, but these errors were encountered: