Skip to content
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
Closed

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

darvin opened this issue May 30, 2013 · 27 comments
Labels

Comments

@darvin
Copy link

@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
Copy link
Contributor

@tj 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
Copy link

@michaelBenin michaelBenin commented Feb 25, 2014

Please reconsider this issue.

@sukima
Copy link
Contributor

@sukima 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
Copy link
Contributor

@sukima 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
Copy link

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

@tj
Copy link
Contributor

@tj 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
Copy link
Contributor

@sukima 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
Copy link
Contributor

@tj 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
Copy link

@michaelBenin michaelBenin commented 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?

@sukima
Copy link
Contributor

@sukima 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
Copy link

@bevacqua bevacqua commented 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?

@sukima
Copy link
Contributor

@sukima 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
Copy link
Contributor

@tj tj commented Mar 14, 2014

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

@michaelBenin
Copy link

@michaelBenin michaelBenin commented 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"

michaelBenin added a commit to michaelBenin/mocha that referenced this issue Apr 22, 2014
- Add: browser property to package.json specifying lib/mocha_browserify.js
- Fix: require calls in the browser mocha.js
@michaelBenin
Copy link

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

sukima added a commit to sukima/mocha that referenced this issue Apr 23, 2014
This will tell any browserify project to package the browser version of
mocha and not the Node version.

Fixes issue mochajs#880

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

@ksikka 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
Copy link

@markmenox markmenox commented 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

@ksikka
Copy link

@ksikka ksikka commented Oct 3, 2015

@tj reopen?

@markmenox
Copy link

@markmenox markmenox commented 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

@boneskull boneskull reopened this Oct 4, 2015
@boneskull
Copy link
Member

@boneskull boneskull commented Oct 4, 2015

I'm reopening this, but tentatively.

Maybe mochify will help you guys.

@boneskull
Copy link
Member

@boneskull boneskull commented Oct 21, 2015

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

@SonofNun15
Copy link

@SonofNun15 SonofNun15 commented 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?

@kuraga
Copy link

@kuraga kuraga commented Dec 22, 2015

Yes, why?

@kuraga
Copy link

@kuraga kuraga commented Dec 22, 2015

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

@Sigfried
Copy link

@Sigfried Sigfried commented Feb 3, 2016

Same issue here with webpack.

@tswaters
Copy link

@tswaters 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
Copy link

@AlastairTaft 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

You can’t perform that action at this time.