Uncaught module 'emitter' not found

[Leonhardt Wille]

Shouldn't it be "events"?

I'm using superagent in the browser with stitch, cf my comment on 8acb989.

[TJ Holowaychuk]

i have a different module for the client called "emitter" for something I'm working on, but maybe we can add support for "events" since browserify will use this too

[Leonhardt Wille]

Okay, I think I messed up something. You're checking for an "exports" variable which should only exist when running on node. But stitch is supplying module, exports and all that stuff in the client.

Also, the events.js is only working when prepended to superagent.js - not when required via the CommonJS interface (it's missing a module.exports). I'll make a pull request if you like.

[TJ Holowaychuk]

well the thing is that it's detecting exports for a thing I have in the works, which just happens to use "emitter" instead of node's one because it has a slightly different API and removes the require('events').EventEmitter fluff. We would need a way to tell which environment this thing is in even with both module and exports is present

[Eirik A]

Yeah, it would be nice to be able to use this with browserify as well.

One alternative I can see is to set a different main with browserify, i.e. specify "browserify" : "browserifyEntry.js" in package.json. Then move the eventEmitter stuff to the two entry points, and injected the right one in those. This should make the packaged code slimmer as well.

[Tomas]

👍 having this issue while using superagent inside node-webkit (and I don't know why it doesn't find EventEmitter - @rogerwang maybe?)

[Tomas]

I've just found out it's because of superagent index.js file:

if (typeof window != 'undefined') {
  module.exports = require('./lib/superagent');
} else if (process.env.SUPERAGENT_COV) {
  module.exports = require('./lib-cov/node');
} else {
  module.exports = require('./lib/node');
}

:| I don't know if this is node-webkit responsibility or superagent's.

[jduncanator]

@tomasdev It's super agents. However things could get complicated and messy when detecting node-webkit over browsers. I'd suggest something like:

if((typeof process != 'undefined' && process.versions['node-webkit']))
    // This is node-webkit!

[Garrett Johnson]

@tomasdev thats odd... superagent supports the browser and node, not sure what node-webkit could be doing to mess up the node or webkit side of things.

[Garrett Johnson]

Closing this for now because people are using superagent fine in the browser via the download file, component or even browserify.

@tomasdev I am certain that's going to be node-webkit's problem, but feel free to open a newer issue if you feel differently.

[jduncanator]

@gjohnson The issue is that node-webkit exposes a global window variable which causes superagent to think its running in a browser, even tho node-webkit supports the full Node.js APIs.

[TJ Holowaychuk]

gah haha fragmentationnnn..

[Roger Wang]

@tomasdev I'm considering removing the window reference from Node context in node-webkit. I'm not sure whether other developers would need it.

[jduncanator]

@rogerwang What exactly do you mean?

[Roger Wang]

I mean the global window variable which causes superagent to think its running in a browser. Some other JS libraries use this way too. In order not to confuse them I'm thinking to remove it from the Node context of node-webkit, so JS libraries would run smoothly.

[jduncanator]

@rogerwang But would that not affect all the other applications built to use window? I'm not sure I understand what you mean by "Node Context"

[Garrett Johnson]

@rogerwang @jduncanator @tomasdev I am interested in this conversation, but for the sake of other watchers/maintainers on here, let's move this to a thread on node-webkit. Please paste the issue link. Thanks!

[Roger Wang]

Please discuss here in future: nwjs/nw.js#1588