New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
darvin opened this Issue May 30, 2013 · 27 comments

Comments

Projects
None yet
@darvin

darvin commented May 30, 2013

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

This comment has been minimized.

Show comment
Hide comment
@tj

tj May 30, 2013

Contributor

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?

Contributor

tj commented May 30, 2013

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?

@tj tj closed this May 30, 2013

@michaelBenin

This comment has been minimized.

Show comment
Hide comment
@michaelBenin

michaelBenin Feb 25, 2014

Please reconsider this issue.

Please reconsider this issue.

@sukima

This comment has been minimized.

Show comment
Hide comment
@sukima

sukima Mar 4, 2014

Contributor

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.

Contributor

sukima commented Mar 4, 2014

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

This comment has been minimized.

Show comment
Hide comment
@sukima

sukima Mar 4, 2014

Contributor

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)

Contributor

sukima commented Mar 4, 2014

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

This comment has been minimized.

Show comment
Hide comment
@michaelBenin

michaelBenin Mar 4, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@tj

tj Mar 4, 2014

Contributor

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

Contributor

tj commented Mar 4, 2014

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

This comment has been minimized.

Show comment
Hide comment
@sukima

sukima Mar 4, 2014

Contributor

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.

Contributor

sukima commented Mar 4, 2014

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

This comment has been minimized.

Show comment
Hide comment
@tj

tj Mar 4, 2014

Contributor

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

Contributor

tj commented Mar 4, 2014

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

This comment has been minimized.

Show comment
Hide comment
@michaelBenin

michaelBenin Mar 5, 2014

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?

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

This comment has been minimized.

Show comment
Hide comment
@sukima

sukima Mar 5, 2014

Contributor

@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.

Contributor

sukima commented Mar 5, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@bevacqua

bevacqua Mar 14, 2014

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?

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

This comment has been minimized.

Show comment
Hide comment
@sukima

sukima Mar 14, 2014

Contributor

@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.

Contributor

sukima commented Mar 14, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@tj

tj Mar 14, 2014

Contributor

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

Contributor

tj commented Mar 14, 2014

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

@michaelBenin

This comment has been minimized.

Show comment
Hide comment
@michaelBenin

michaelBenin Apr 22, 2014

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"

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 added a commit to michaelBenin/mocha that referenced this issue Apr 22, 2014

Issue #880: browserify compatibility
- Add: browser property to package.json specifying lib/mocha_browserify.js
- Fix: require calls in the browser mocha.js
@michaelBenin

This comment has been minimized.

Show comment
Hide comment
@michaelBenin

michaelBenin Apr 22, 2014

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.

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.

sukima added a commit to sukima/mocha that referenced this issue Apr 23, 2014

Add browser script option to package.json
This will tell any browserify project to package the browser version of
mocha and not the Node version.

Fixes issue #880

This will only cover the JavaScript packaging, CSS is still done
manually through <link> tags.
@ksikka

This comment has been minimized.

Show comment
Hide comment
@ksikka

ksikka Sep 27, 2015

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).

ksikka commented Sep 27, 2015

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).

@markmenox

This comment has been minimized.

Show comment
Hide comment
@markmenox

markmenox Oct 3, 2015

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

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

This comment has been minimized.

Show comment
Hide comment

ksikka commented Oct 3, 2015

@tj reopen?

@markmenox

This comment has been minimized.

Show comment
Hide comment
@markmenox

markmenox Oct 4, 2015

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

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 boneskull reopened this Oct 4, 2015

@boneskull

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Oct 4, 2015

Member

I'm reopening this, but tentatively.

Maybe mochify will help you guys.

Member

boneskull commented Oct 4, 2015

I'm reopening this, but tentatively.

Maybe mochify will help you guys.

@boneskull

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Oct 21, 2015

Member

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

Member

boneskull commented Oct 21, 2015

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

@SonofNun15

This comment has been minimized.

Show comment
Hide comment
@SonofNun15

SonofNun15 Oct 27, 2015

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?

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

This comment has been minimized.

Show comment
Hide comment
@kuraga

kuraga Dec 22, 2015

Yes, why?

kuraga commented Dec 22, 2015

Yes, why?

@kuraga

This comment has been minimized.

Show comment
Hide comment
@kuraga

kuraga Dec 22, 2015

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

kuraga commented Dec 22, 2015

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

@Sigfried

This comment has been minimized.

Show comment
Hide comment
@Sigfried

Sigfried Feb 3, 2016

Same issue here with webpack.

Sigfried commented Feb 3, 2016

Same issue here with webpack.

@tswaters

This comment has been minimized.

Show comment
Hide comment
@tswaters

tswaters Feb 7, 2016

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

tswaters commented Feb 7, 2016

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

boneskull added a commit to boneskull/mocha that referenced this issue May 23, 2016

boneskull added a commit to boneskull/mocha that referenced this issue May 23, 2016

boneskull added a commit to boneskull/mocha that referenced this issue May 23, 2016

boneskull added a commit to boneskull/mocha that referenced this issue May 23, 2016

@boneskull boneskull closed this in 524862b May 23, 2016

@boneskull boneskull removed the help wanted label Oct 10, 2016

@AlastairTaft

This comment has been minimized.

Show comment
Hide comment
@AlastairTaft

AlastairTaft Nov 5, 2017

Came here to offer my 2 cents for a webpack workaround

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

AlastairTaft commented Nov 5, 2017

Came here to offer my 2 cents for a webpack workaround

resolve: {
  alias: {
    stylus$: 'stylus/lib/stylus',
  },
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment