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

[cetra3]

@gaearon The webapp has a lot of other frameworks loaded, and unless we tippy toe around them, we run into really strange errors, especially if the define global is continuously reimplemented. It's something sort of out of my hands, as we're only changing a small part in a 5+ year old code base.

@mjackson I understand that bower is not welcome in some circles, and is quickly turning legacy. But, we need a strong migration path if this is the case to allow devs to dip their feet in the water without having to make changes to their build infrastructure and tooling. It means we can reduce the amount of changes necessary to start using it, if that makes sense.

[gaearon]

The webapp has a lot of other frameworks loaded, and unless we tippy toe around them, we run into really strange errors, especially if the define global is continuously reimplemented. It's something sort of out of my hands, as we're only changing a small part in a 5+ year old code base.

UMD build should work just fine unless there's a global define or module variable. Of course, if there is, it will assume we're in AMD environment. If you have a global define which is not AMD, that's a problem with your setup. If you solve it, you'll be able to use UMD build.

[gaearon]

But, we need a strong migration path if this is the case to allow devs to dip their feet in the water without having to make changes to their build infrastructure and tooling.

1. Add package.json
2. Put redux there
3. Grab node_modules/redux/dist/redux.min.js
4. Eventually start using npm for more dependencies

You don't have to stop using Bower to begin using npm. In fact that's how most project migrate—by using both for some time.

[cetra3]

@gaearon in that scenario, how do we compile/minify our js assets to the one vendor.js file? I can imagine it getting messy when you introduce thunk & react, having to explicitly include js files.

[gaearon]

in that scenario, how do we compile/minify our js assets to the one vendor.js file? I can imagine it getting messy when you introduce thunk & react, having to explicitly include js files.

You can use UMD builds of React, Redux, ReactRedux. They all ship with NPM packages. Smaller packages like redux-thunk don't have UMD builds—for them, you need to either use a bundler or contribute a UMD build pull request to them. However, redux-thunk is a five-liner and unlikely to ever change, so you might as well copy it to your project. This should give you a good enough start.

[cetra3]

@gaearon Thanks for the advice!

I'm wondering if there might be a good article that describes how to migrate from bower that can be linked somewhere.

[gaearon]

There it is:
http://gofore.com/ohjelmistokehitys/stop-using-bower/

[klebba]

@mjackson Maybe you should check out WebComponents some time. Then you can let me know if you still think npm is the right tool for their distribution.

@gaearon I have no reason to keep this issue open any more; feel free to close it.

[gaearon]

It's already closed. Nevertheless I'm grateful for your input and if you'd like to continue discussing what keeps you from adding npm to you workflow, I'm happy to. It might help others in the same situation.

Maybe you should check out WebComponents some time. Then you can let me know if you still think npm is the right tool for their distribution.

In my opinion this is not a great way to have a conversation. For example, I have an idea about web components, but I don't know at all why npm doesn't fit their model. In fact googling "web components npm" gives me plenty results both for the polyfills and the components themselves.

Don't forget npm is just a package manager. It's a thing that lets you host files. People saying it's just for JavaScript (and you can't put HTML, CSS, or whatever web components need there) are misleading you. It's not true.

Unless you enlighten us as to why npm is a poor fit for web components it's hard to continue the conversation.

Still, if you have specific concerns about NPM or using UMD builds we provide for the core projects, please write them up, and we'll try our best to figure out a solution to your case. But please don't assume we're just being unhelpful for the sake of doing this, or that we have an irrational hate for Bower. I used Bower in my own projects, and migrated to npm later. I'm not just hating on the tech I don't use. I want to help you stop using it because it's problematic software, for users and maintainers.

[klebba]

@gaearon Let me start by saying my intention here is not to start a discussion which will persuade you and others to change your opinion of Bower. I don't care if you use this tool, but I've already stated that I must at the moment. You seem to think that I should wise up and use npm. But npm is simply not a drop-in replacement for Bower in every scenario. The npm blog from 2014 outlines why in this article, under "Front-end pain points":

http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging

Bower's flat dependency list is an important design choice for projects built around WebComponents. How do you reproduce this behavior this with npm?

[SimenB]

(npm@3 is flat by default)

[gaearon]

The npm blog from 2014 outlines why in this article, under "Front-end pain points":

A year has passed since then. ;-)

Bower's flat dependency list is an important design choice for projects built around WebComponents. How do you reproduce this behavior this with npm?

NPM 3 has been stable for about a month now, and it also implements a flat dependency list. Unlike Bower, it is also able to handle version conflicts by nesting dependencies, but unless you have version conflicts between several dependencies, NPM 3 maintains a flat dependency list.

But npm is simply not a drop-in replacement for Bower in every scenario.

As said above, even if you have problems using NPM for all your dependencies, you can start using it for some projects. Like Redux.

[klebba]

Ok, that's great -- when the dependencies of my project cut over to npm I will gladly do the same. I can't combine npm and Bower dependencies; every package must be a sibling of the other packages in the project.

FYI, here is the counter-discussion in the Polymer project: Polymer/polymer#2578 -- in short they aim to switch over once npm supports conflict resolution

[ryanflorence]

bower install https://npmcdn.com/redux@3.0.4/dist/redux.js works, so ...
bower install whatever=https://npmcdn.com/redux@3.0.4/dist/redux.js if you want to name it

[unthunk]

You guys. You should all quit using hammers because everyone is switching to screwdrivers. So you should definitely use a screwdriver. Plus I heard nobody is actively developing hammers now.

[gaearon]

Everybody, thank you for your concern and the discussion.

At this point I think we've made our position clear and offered both good rationale for switching to npm 3 (Bower no longer being actively maintained, npm 3 having flat dependencies and superior conflict resolution), and a possible workaround (point Bower to npmcdn or cdnjs and use the UMD build).

Being snarky about it doesn't help anyone.
This is why I'm locking this thread.