Browserify couldn't resolve "require('rx')"

[aokros]

I've made a simple fix in the "support for build optimizers" part of intro.js since it tried to require the non-existent "rx" bower package. As the result of the fix now it depends on the existing "rxjs" bower package thus it's possible to use rxjs-dom with browserify.

[adamrecsko]

+1

[mattpodwysocki]

@aokros it was rx because the main NPM package is rx not rxjs, but Bower differs here. So, what's the right answer? Do we need to support both or just Bower?

[benlesh]

Bower is a horror-show, IMO.

• it's a straight facade over GitHub. If someone kills their repo or a tag you were pointing at, it breaks your builds.
• it has weird features around conflicted dependency resolution. Just because I tell it "!3" (use selection 3 and persist it), it doesn't actually seem to persist for others working on my project. This means I could be working with a different version of a library than the developer sitting next to me.

Bower needs to fade away.

[benlesh]

Also, I don't use Browserify often, but it's my understanding that it uses node_modules to resolve dependencies pulled in with require, not bower.

[aokros]

@mattpodwysocki This is a tricky question since the way we use browserify is not the "standard" way, if there is a "standard" way at all. We use it with "debowerify" and the npm packages are on a different path, so the browserify can only access the "debowerified" packages.
Another aspect of this: we are using rx-dom as a bower package, so it's natural to expect the dependencies as bower packages. The "rx-dom" bower package has to depend on "rxjs" bower package, and the "rx-dom" npm package has to depend on "rx" npm package. These dependencies are correctly captured in the bower.json and package.json files, but the intro.js still has to be adjusted.
After I thought this over it seems my change is not the best. What do you think?