Support installation via Bower

[klebba]

I already read the discussion in #579...

In this thread @gaearon said "I'm up for 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

[gaearon]

In this thread @gaearon said "I'm up for supporting Bower if there is enough interest in it."

Yes, and later in that same thread I said

Using Bower is a bad idea. If you use Bower and want to fork the repo, please do it, but we won't support it. I explained above that it makes little sense with Redux's ecosystem because most of complementary packages are small and are all on NPM.

I've made a decision and won't change it, sorry.

"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

Do you honestly think maintaining an additional repo is free and takes no time?

Also, If I start maintaining Redux Bower package, people will expect me also to maintain Redux DevTools Bower package, React Redux, Redux Thunk, etc. Redux is not backed by a company, unlike React, and I don't have the horsepower to do what they do.

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.

We are neither React nor Flux. This is not a Facebook repository. If Facebook chooses to maintain Bower packages for their repos, it's cool. But we won't.

And yes, we can claim that using Bower is a bad idea because it really is. It is your choice to ignore this and use an inferior tool, but then please feel free to create redux-bower and maintain the releases yourself. Contribute back!

Ultimately I've had to spend the most time out of all of the dependencies in my project to include redux

Here, let me help you:

bower install https://cdnjs.cloudflare.com/ajax/libs/redux/3.0.4/redux.js

[cetra3]

Hi @gaearon, I'll be making a redux-bower repo when I have some time. Hoping to get my hands dirty with rollupjs to produce a nice build.

Are you against using the cloudfare version as a starting point?

[gaearon]

@cetra3

Please be careful about Rollup because we might later change build process in a way that isn't compatible with Rollup. See #611.

Yes, you can use the UMD build from Cloudfare. I'm not sure what exactly is the point of maintaining a Bower package if you can point Bower to a CDN url just fine.

Also, @mjackson recently made a thing called npmcdn.com, so you may also point Bower at https://npmcdn.com/redux@3.0.4/dist/redux.min.js.

[cetra3]

Ok, I'll keep that in mind about rollupjs.

The intention is to have a version which uses globals rather than depending on UMD, as this makes it a challenge to introduce it into some of the existing webapps we integrate for. This is opposed to a library such as angular, which doesn't really depend on webpack/browserify so you can just drop it in anywhere.

Not sure if there's a webpack way of producing an iife/globals only version, as that would solve the problem!

As for using the URL, among other things it's not totally compatible with resolvers. It's also much nicer to have proper tagged releases.

[gaearon]

I might have not made this clear.
UMD is globals.

UMD is a module format that works by detecting the current environment and it supports both AMD, CommonJS and globals.

If you drop a UMD build in a browser as a script tag you'll end up with Redux global. However it will also work if you require it in an AMD or CommonJS project. That's why it's called a "universal" module definition.

Does this help?

[gaearon]

Redux does not depend in any way on Webpack or Browserify. We say this in README. We recommend them but explicitly say you can use globals.

Is there some way we can make this more obvious? It would be a bummer if many people make the same mistaken assumption. :-( Please see the README:

This assumes that you’re using npm package manager with a module bundler like Webpack or Browserify to consume CommonJS modules.

If you don’t yet use npm or a modern module bundler, and would rather prefer a single-file UMD build that makes Redux available as a global object, you can grab a pre-built version from cdnjs. We don’t recommend this approach for any serious application, as most of the libraries complementary to Redux are only available on npm.

[gaearon]

As for using the URL, among other things it's not totally compatible with resolvers.

Curiously the docs you linked to say custom resolvers can be used to install packages from NPM. Wouldn't that solve the problem in the first place?

[mjackson]

@cetra3 I would strongly recommend against using bower. The project is not actually maintained by anyone and places an unnecessary burden on package authors.

[klebba]

@mjackson Neither of these things is true. Here's the Bower release history: https://github.com/bower/bower/blob/master/CHANGELOG.md

Many projects continue to recommend Bower for their distribution; for example Polymer (and WebComponent projects in general): https://www.polymer-project.org/1.0/docs/start/getting-the-code.html

Further, it is currently not possible to use npm to install Polymer: http://stackoverflow.com/questions/31128784/can-i-install-polymer-1-0-with-npm

If you think you know better than the silly people that require support for this package manager, that's fine. Don't support it. But it's bizarre to discourage outside workarounds. @cetra3 I would be glad to see redux-bower

[mjackson]

@klebba I'm getting my information directly from people who started and maintain the bower project. New feature development is effectively stopped and everyone who either started the project or built any major piece of it has effectively stepped away.

As for the burden that bower places on package authors, this very issue is evidence of that. I've experienced similar issues in every OSS project I've ever worked on, and I'm not the only one.

As for my part, I will do my best to use what influence I have to convince people to stop using bower until such time as I see they fix the issues with the project and develop a serious strategy for moving it forward. I refuse to support it on any of the rackt projects that I maintain and I encourage other rackt authors to do the same.

As it currently exists, bower is bad for the JavaScript ecosystem. Plain and simple.

[klebba]

@mjackson Do you have an alternative solution to offer for projects that depend on WebComponents such as Polymer elements? I'm not here in defense of Bower; it's just a tool that I must use. I couldn't care less if you use it.

[mjackson]

We are not the ones making things difficult for you here. Polymer is.
Literally every other js library I know publishes to npm. It boggles the
mind that Polymer does not.

Why don't you make a polymer-npm repo? It will be at least as much work as
creating a redux-bower repo, and then you get to use npm and never have
this conversation with anyone ever again.
On Sun, Nov 8, 2015 at 12:57 PM Casey notifications@github.com wrote:

@mjackson https://github.com/mjackson Do you have an alternative
solution to offer for projects that depend on WebComponents such as Polymer
elements https://elements.polymer-project.org/? I'm not here in defense
of Bower; it's just a tool that I must use. I couldn't care less if you use
it.

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