Consider dropping support for bower

[unscriptable]

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

[KidkArolis]

+1 for dropping.

If rave focuses on npm and having really good experience there - we might
just eliminate the need for bower all together. Npm is a brilliant package
manager and can work very well for frontend in theory. In practice there
are a few issues and its important there is more tooling that fixes those
issues. Browserify is great but not always an option.
I'd rather have rave make steady progress and simpler code in order to work
well with npm. And revisit bower question later if at all.

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
https://github.com/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 https://github.com/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
bclozel/gulp-bower-src#5
[2] https://github.com/ck86/main-bower-files
[3] bower/spec#10
bower/spec#10
[4] bower/spec#23
bower/spec#23
[5] bower/spec#22
bower/spec#22

—
Reply to this email directly or view it on GitHub
#59.

[briancavalier]

+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.

[unscriptable]

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?

[phated]

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.

[KidkArolis]

I recently switched a project from bower to npm at work, and all i had to
do was move the list of deps from bower.json to package.json. i.e.
basically npm supports all the same features (installing from git) and most
bower packages don't have dependencies since .. It's hard to depend on
things in bower.

Its cool bower is currently supported.
I wouldn't actively pursue better support though.

I personally consider bower somewhat harmful..
On Sep 27, 2014 2:11 AM, "Blaine Bublitz" notifications@github.com wrote:

With all the new changes
http://blog.npmjs.org/post/94662089625/the-future-of-the-npm-website-lets-map-this-road
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.

—
Reply to this email directly or view it on GitHub
#59 (comment).

[chrylis]

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.

[briancavalier]

Its cool bower is currently supported.
I wouldn't actively pursue better support though.

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.

[unscriptable]

Its cool bower is currently supported.
I wouldn't actively pursue better support though.

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.