Request: `this` binds to the window rather than the exports object. about browser-pack HOT 14 CLOSED

In node.js modules, this === module.exports. Changing that would break any node modules that currently use this this way.

from browser-pack.

browserify/browserify#372

from browser-pack.

@mscdex @epeli thanks for the additional info.

I am empathic to this point made by @epeli earlier

On the other hand I've never seen anyone using this to export stuff from node.js modules. People are always using exports or module.exports explicitly. Assigning this to window could be very practical for non-CommonJS libraries, but it wouldn't be the most node.jsish way.

I personally wasn't even aware that this was bound to module.exports in Node, and I am no newb. I just haven't seen this recommended or documented anywhere. Does anyone know of an active module which actually uses this instead of module.exports?

I am currently working on making deamdify work with a larger set of libraries, and as you can imagine, authors who publish in AMD may not be clued in to how Browserify/Node works.

from browser-pack.

Remember to think about the worst case too: When you actually encounter a module that uses this to expose stuff and you browserify that module you get very sneaky global leaks...

Personally I'd say no to this request.

from browser-pack.

This would break a lot of node code in the browser.

from browser-pack.

Okay. I'll opt for the workaround of wrapping the amd modules with an iife.

from browser-pack.

Okay, so how should library address window to be compatible with browserify?
Just ran into issue related to this in eligrey/FileSaver.js#57 and would appreciate any insights on how to address the matter in case script to need to access to window variable while being used with browserify.

from browser-pack.

@Sudoki Just use window instead of this. I never got why people don't just do that.

from browser-pack.

I wonder if browserify-shim transform can have a configurable option to wrap such "modules" into a function which executes in window's context? /cc @thlorenz

from browser-pack.

@substack some older libs still use this cause they expect to run on script level. It makes it hard to use those with browserify even with browserify-shim. Even though that is not browserifys fault, if there was a way to make this work out of the box that'd be great.

@andreypopp I'd rather find a solution that works for all modules. If you think this can (and should) be solved via browserify-shim, please file an issue (ideally with repro case) over there and we can figure out how to do that.

from browser-pack.

The workaround I used was:

;(function(){
   // original code
}.call(window));

from browser-pack.

Since this is very browser specific, adding it to browserify would break things in node (you can run a bundle in node).

Would this problem be solved if browserify-shim would wrap modules like this? Possibly the issues appear most likely when shimming modules?

from browser-pack.

@thlorenz yeah, that's what I mean, it would be done before being passed to browserify.

from browser-pack.

So we'll fix it in browserify-shim then.

I'd appreciate an issue with a repro case in the browserify-shim issues :)

from browser-pack.