Bower's future in jeopardy?

asuh · November 13, 2015, 9:36pm

The one maintainer of Bower said he’s not sure how to get much done on no budget and limited workforce.
https://github.com/bower/bower/pull/1748#issuecomment-150104311

I’m not sure if that should be considered in how front-end packages are added to Sage but it’s an ongoing development to keep watch.

Edit: More word of mouth details:

github.com/reduxjs/redux

Support installation via Bower

opened 11:46PM - 23 Oct 15 UTC

closed 08:42AM - 24 Oct 15 UTC

klebba

infrastructure

I already read the discussion in #579... In this thread @gaearon said "I'm up f…or supporting Bower if there is enough interest in it." but if the thread is locked no one can express their interest. "We won't put build products into Git repo. Otherwise every second new PR will contain changes to the built files, because people will keep doing this." Just do this: https://github.com/reactjs/react-bower React/Flux does provide distribution via Bower, so it is bizarre to declare that "Using Bower is a bad idea" and leave it at that. Ultimately I've had to spend the most time out of all of the dependencies in my project to include `redux`

karatechops · November 15, 2015, 4:36pm

This is a really interesting topic I’ll be watching pretty closely as I do enjoy my Bower workflow with Sage. With that said I’d love to see more innovation regarding front end package management, all too often devs don’t setup or maintain their bower packages properly.

icc97 · November 17, 2015, 4:53pm

Comment from sherun the project owner:

If it’s not clear yet: bower is stable software, bower is not dying, bower looks for contributors and funding.

asuh · November 17, 2015, 5:14pm

Right, it’s somewhat reassuring but it’ll be interesting to see the progress of help or support.

I keep reading more and more devs are promoting to just use NPM3 as a package manager vs Bower. Here’s a recent Twitter discussion about it.

I prefer Bower b/c keeping Front-end scripts and Back-end scripts separate has its benefits but the ease of use of using NPM3 could also be beneficial for other reasons.

ben · November 20, 2015, 12:17am

http://bower.io/blog/2015/bower-alive-looking-contributors/

ben · November 20, 2015, 12:19am

Twansparant · November 20, 2015, 9:09am

Curious where this is going…
It would require a new Gulp workflow since the front-end scripts should compile with Gulp, but the backend scripts shouldn’t.

mAAdhaTTah · November 21, 2015, 4:08pm

Does this suggest Sage 9.0 will use npm/Browserify? I remember a comment (related to introducing composer) that we’d have to deal with 3 different package managers. Using npm for all of the JavaScript depdendencies and composer for all the back-end would resolve that issue.

ben · November 21, 2015, 7:14pm

We’re leaning towards bringing Webpack into the next iteration of the Sage workflow

John · November 24, 2015, 6:10pm

In this case, would there need to be some sort of transition from sage sites using bower or leave as is. Especially, if Bower becomes more unsupported or than supported. Ive had a steep learning curve with bower and it makes me sad that things may change so soon.

I sometimes miss the days of Roots 6.0. I still have a site I maintain on 6.5.2 and every time I type in grunt I wait for an error, but it keeps chugging along.