browserify breaks at require('./lib-cov/mocha')

[darvin]

mocha/index.js:

module.exports = process.env.COV
  ? require('./lib-cov/mocha')
  : require('./lib/mocha');

Error: module "./lib-cov/mocha" not found from "/Volumes/work/Projects/yaas/node_modules/mocha/index.js"

[tj]

sucks to be browserify I guess, I'm not breaking test coverage just for that. I thought browserify does all its hacky stuff to populate fake process variables etc?

[michaelBenin]

Please reconsider this issue.

[sukima]

First off, the process has nothing to do with it. Browserify sees that the above has two require statements. Therefore it goes to include both and finds the lib-cov directory missing. It's a pre compiler not a runtime.

Whether the merits of such an implementation of a pre-compiler is in question or not it would seem that assuming a node based project could be used in browser via such a tool is faulty.

I would highly recommend that a fork of mocha offer a browser compatible solution. Yes mocha works in browser but it is not browserify friendly. The npm ecosystem however could support spin-off projects such as mocha-browserify or something (if one were writen, which as of this comment one has not). It is sad it has to be that way but with such a fractured ecosystem in the javascript world there is no way to expect every library maintainer to support every possible option out there. (a quick look did find mochify, not exactly what the OP asked).

Or you could look into a more browserify friendly test framework like Jasmine. Hope that helps.

[sukima]

I also forgot. If you use testem or mochify then you can use mocha with browserify. Just don't require('mocha') in your browserified code. testem and mochify will inject mocha correctly. (tested in testem; never used mochify)

[michaelBenin]

Sukima thank you for your recommendations. Testem is an awesome library and I plan on using that for x browser testing for my Window's deployments but locally and in Jenkins, I like to use grunt-mocha which uses this library.

I've resulted into putting a script tag of mocha in my page but I feel that browserify is gaining traction as an awesome tool and Mocha should consider supporting it.

[tj]

if we remove the lib-cov will it work? or do we need other hacks as well? I'd be ok with removing that line for now

[sukima]

Unfortunately I tried that. Once browserify makes it past that line it hits other ./lib-cov requires deeper in the chain. We could conceivably include the lib-cov modules in the node_modules build. However, then we will include two libs instead of just one. It is a shame browserify won't recognize conditional requires.

The real answer to the problem is that the npm version of mocha is designed for node and browserfiy is hacking it back out into the browser. When what it should be doing is using the browser build for mocha. So my suggestion is to offer the browser version in a separate npm package. The advantage there is browser based projects can use npm to manage the mocha lib and browserify happily takes care of it.

For clarity the sinon project suffers the same problem of straddling both worlds. When asking browserify to include sinon it includes the node version which lacks some features. You have to manually require the browser version buried in the node_modules tree. I got around the pain using a test runner like testem:

{
  "framework": "mocha+chai",
  "serve_files": [
    "node_modules/sinon/pkg/sinon.js"
  ]
}

I also don't know what build of mocha testem is including with their project since the above is asking testem to inject their own copy of mocha into the served HTML file. Whether that's packaged in testem or pulled from mocha (via node_modules) I don't know. I'd have to go spelunking the source.

I hope that clears up the confusion.

[tj]

yeah, they're fundamentally quite different (none of the reporters are useful on the client etc) so separating may be a good idea some day regardless of browserify. Ideally this works with component as well but it was pre-component and back when browserify 1.x wasn't too great

[michaelBenin]

FTR, my use case is a lot of my code is shared between the client and server with browserify, I really enjoy using mocha, the way I've solved this isn't clean for my shared tests. I export a function that takes mocha as the param and contains logic for both client and server, on the server it takes a require('mocha') as the param, on the client, window.mocha, as it's loaded in with a script tag because of this issue. Does anyone have any other suggestions besides browserify where I can use mocha? Or should I switch to Jasmine?

[sukima]

@michaelBenin I've handled this by having two different launchers. a test.html which has a <script src="path/to/mocha.js"> in it. Then a specs.js with a require('mocha') in it. In both cases mocha is exported to the global namespace offering the standard describe/it functions as expected. Same thing for other global-ish libs like chai and sinon.

Than in node you run the specs.js and in the browser you open test.html. In your actual test files which would be compiled in browserify just skip the whole require('mocha') statement since either of the two launching environments already handle it.

Again test runners like testem automate this process for you. Hence, why I offered a possible configuration example above.

[bevacqua]

Configuring an alias like this, in Browserify, sort of works.

alias: [
  'node_modules/mocha/lib/mocha.js:./lib-cov/mocha'
]

Except it still finds Jade deeper into the chain. And... it's a tremendously horrible hack. Suggestions?

[sukima]

@bevacqua read my comment above. It explains that you include the browser version of mocha in your test runner (i.e. .html file?) and not as part of your browserify require chain. Again something like testem has that built in by selecting the "framework": "mocha" option.

[tj]

wtf haha why is it loading jade, leaky abstractions be leaking

[michaelBenin]

in package.json i believe this might work if you specify (mocha.js is commonjs)

"browser": "./mocha.js"

From docs:

browser field

There is a special "browser" field you can set in your package.json on a per-module basis to override file resolution for browser-specific versions of files.

For example, if you want to have a browser-specific module entry point for your "main" field you can just set the "browser" field to a string:

"browser": "./browser.js"

[michaelBenin]

So I have it working bundling.

Basically had to copy over mocha.js into lib, renamed require to rqr, and declared and exported mocha.

Still going to just keep the script tag though.

[ksikka]

I'm still unable to browserify a file that require's mocha. Error:

Error: Cannot find module './lib-cov/mocha' from '/Users/ksikka/test_mochify/node_modules/mocha'

Anyone else in the same boat?

Tried it with node 0.10, 0.12, the latest browserify in npm (11.2.0), the latest mocha in npm (2.3.3).

[mmenoxx]

Same here with node 4
even if i have:
"browser": {
"debug": "./lib/browser/debug.js",
"events": "./lib/browser/events.js",
"tty": "./lib/browser/tty.js",
"mocha": "./mocha.js"
},

in package.json of mocha module

[ksikka]

@tj reopen?

[mmenoxx]

Yes it should be defenitively. Right now it is broken with browserify and the only solution i have for the moment is to keep mocha library (with all my js files that use it), out of browserify process

[boneskull]

I'm reopening this, but tentatively.

Maybe mochify will help you guys.

[boneskull]

don't need whatever ancient coverage stuff is baked in. we should use something else.

[SonofNun15]

Webpack has the same issue, by the way. Why is mocha conditionally requiring a file that does not exist? Is this file generated under some conditions? What triggers this file to be generated?

[kuraga]

Yes, why?

[kuraga]

Should be "browser": "./support/browser-entry", no?

[Sigfried]

Same issue here with webpack.

[tswaters]

Why is mocha conditionally requiring a file that does not exist? Is this file generated under some conditions? What triggers this file to be generated?

@SonofNun15 It's all in the makefile. when running test-cov it uses the jscoverage tool to instrument the code into lib-cov - then mocha runs with the COV environment variable set to report out coverage for the instrumented code.... The initial discussion is in #5 and d4666c2 is the initial commit.

@boneskull I see you added PR PLEASE -- what's the scope of a PR you'd accept? To switch coverage to something less obtrusive -- or get require('mocha') under browserify working?

I think this can be fixed by ignoring lib-cov/mocha, i.e. adding "./lib-cov/mocha": false to the browser field in package.json

[AlastairTaft]

Came here to offer my 2 cents for a webpack workaround

resolve: {
  alias: {
    stylus$: 'stylus/lib/stylus',
  },
}