browserify 2 support

[jhnns]

If anyone wants to have browserify 2 support, let me know.

[jhnns]

Everything rewire needs is bundler-independent, so it basically "just" has to be adapted to the new browserify api. But since I'm not using browserify anymore I'm currently not implementing it.

[aleclofabbro]

you prefer webpack, i guess .. (i see you developed an adapter) why? i'm using browserify, i don't know webpack iyho, whats worth for me? learning fast webpack or write an adapter for rewire?

[jhnns]

Did you use the browserify plugin? Did it work with browserify 2 as well? Or do you still use browserify 1?

Personally I prefer webpack, because it is more flexible. It comes with many loaders (like CoffeeScript, LESS, style, mocha) and supports different styles (commonjs, amd, components). But since browserify 2 a lot has changed, so browserify might be as good as webpack.

webpack's documentation is still in progress, but the maintainer @sokra is responding fast so this was not an issue for me.

[sokra]

I was mentioned... (Just to prove that I'll respond fast :smile:)

[tphummel]

:+1:

[davidguttman]

:+1:

[jbaiter]

:+1:

[focusaurus]

:+1:

[i-like-robots]

Because I really needed something like Rewire for Browserify I went ahead and did the port, so far it's been working out nicely: https://github.com/i-like-robots/rewireify

[jprichardson]

:+1:

[jhnns]

@i-like-robots Cool! Since I'm not using browserify anymore I'm not too motivated to write a plugin :wink:.

Your implementation is simple and straight-forward. It doesn't work exactly like rewire, but that's ok for client-side modules. It will be a problem for isomorphic modules that run in node.js and in the browser. That's why I decided to stick straight to the node-rewire API for my webpack plugin.

If you're planing to rewrite rewireify to be compatible to the node-rewire API here's some advice:

Rewire circumvents the require.cache so other modules don't require the rewired version. Additionally every rewire()-call creates a new module instance. Furthermore a call of rewire("./moduleA.js") needs to add moduleA as dependency to the bundle. I don't know if browserify exposes the parser api to hack in these kind of things. Concerning globals I think you should also prepend the getImportGlobalsSrc()-content. If you add rewire as dependency of rewireify you can just require all the rewire utility modules like __get__, __set__, getImportGlobalsSrc and detectStrictMode.

Back in the browserify 1 days I hacked a browserify plugin for rewire. May that's some inspiration (although there were some crazy hacks necessary because browserify didn't provide an useful api).

[i-like-robots]

@jhnns Thanks for more information, that's really helpful. I put this together extremely quickly as a proof of concept but I plan on working on it to make it more robust. I studied your implementation thoroughly and it was interesting working out how to lever it into Browserify. Unfortunately Browserify does not readily expose a require function to override but I think I can definitely improve on simply injecting the functions into each and every module!

[jhnns]

Well, you could just take my browserify 1 middleware and adjust it to the new transform api of browserify > 2. All the magic/crazy client-side stuff should still work. You just need to find the browserify-2-equivalents of bundle.register and bundle.require.

[i-like-robots]

That covers a lot of the things I've been thinking about, glad to see some of this stuff has already been solved! Thanks for digging that out for me.

[jhnns]

Could you make any progress yet?

[jsdf]

:+1:

[wookiehangover]

:thumbsup:

[benatkin]

:+1:

[iamrandys]

:+1:

[iamrandys]

Thanks @i-like-robots!! Your rewireify works perfectly! I simply added it to my karma.conf and presto! Thanks again!

    browserify: {
        debug: true,
        transform: [ 'reactify', 'rewireify' ]
    },

https://github.com/i-like-robots/rewireify

[jhnns]

Yep, it's cool. Just wanted to point out that the implementation differs a bit (see above).

[iamrandys]

:+1:

Ah as you stated, I see that rewire is clearing the require cache each time and returning a fresh instance. This is very important when developing unit tests. Rewireify is really close, but my unit tests are failing using because they are all using the same "required" instance and my mock call counts are not as expected when running multiple tests together. If I run the tests one at a time they run fine.

Rewire is exactly what browserify needs, but I don't see any way to clear the require cache in browserify.

Difference to require()

Every call of rewire() executes the module again and returns a fresh instance.

rewire("./myModule.js") === rewire("./myModule.js"); // = false

---

Furthermore a call of rewire("./moduleA.js") needs to add moduleA as dependency to the bundle.

I can easily add moduleA as a dependency in Browserify by calling bundler.require('/moduleA.js', {expose: './moduleA.js').

[traviskaufman]

:+1:

[jhnns]

There's no require.cache in browserify? They somehow must have reverted my pull-request with browserify 2...

[blairanderson]

i want browserify support

[danielyogel]

Browserify support would be great. Thanks!

[thom4parisot]

Pretty much interested by this feature to reuse my tests in karma as well :+1:

[jonykrause]

👍

[cyrilthomas]

how about requirejs?

[jhnns]

I don't know enough about requirejs but since there is no compilation step, I'd assume that it's impossible to inject the __set__- and __get__-method into the private module scope.