mocha: Error: Cannot find module './options' (fresh start)

Trying to create a simple test app from scratch. When executing from CLI, receive this error. If I downgrade to 2.5.3 then all is fine. Trying either of the commands below, error.

$ mocha 
$ mocha --help


Error: Cannot find module './options'
    at Function.Module._resolveFilename (module.js:339:15)
    at Function.Module._load (module.js:290:25)
    at Module.require (module.js:367:17)
    at require (internal/module.js:16:19)
    at Object.<anonymous> (/Users/mikeerickson/Documents/Projects/node/mocha-test/node_modules/.bin/mocha:11:16)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Function.Module.runMain (module.js:447:10)

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 6
Comments: 25 (5 by maintainers)

Most upvoted comments

@damienromito I have experienced this issue soooooo many times with Mocha 3.x, it is just routine to perform

$ npm uninstall -D mocha && npm i -D mocha

Anytime it occurs… I have had success skipping the uninstall action and just reinstall Mocha, but that has not helped 100% of the time. So I just run mocha-install alias and move

alias mocha-install="npm uninstall -D mocha && npm i -D mocha"

and then move on as it fixes it for the time being

+25

mikeerickson on Nov 18, 2016

I also encountered that issue several times without understand the origin of the problem. By the way, I deleteed the /node_modules folder and npm install to fix it.

+12

damienromito on Nov 18, 2016

I encountered this issue when I was running npm install on one machine, making a zip file of all my code and node_modules, and then unzipping the file on another machine. The process of making the zip file turned the symlink at node_modules/.bin/mocha into a regular file, so that when it was installed on the second machine, it would look for ./options in node_modules/.bin instead of in node_modules/mocha/bin.

I fixed the issue by running zip --symlinks to preserve the link from node_modules/.bin/mocha -> ../mocha/bin/mocha

I’m not too familiar with the internals of mocha, but one potential fix would be to move the code in ./options to mocha/bin/mocha (and mocha/bin/_mocha) so that there isn’t a relative import in bin/mocha.

The above fix would duplicate the code in ./options, so if that is undesirable, the “node way” would be to make it a separate module and include the new module as a dependency.

sierranevadan on Mar 20, 2017

The issue with Symlinks is definitely causing the issue updated the detailed here. https://github.com/mochajs/mocha/issues/2582#issuecomment-299851765

ankur-anand on May 8, 2017

I think I had the same issue, related to @sierranevadan 's, excepting that I Rsync’d my whole app structure to a VM guest.

Regardless, I encountered this issue, nuked my local node_modules/ and ran yarn install (npm analogue). After reinstalling everything mocha works as I expect.

mocha 3.2.0, node v6.10.1, yarn 0.21.3

hovissimo on Mar 31, 2017

👍 Glad you got it figure out!

Only other things I’d add are:

NPM does have a --no-bin-links option that is supposed to install without creating the links – although that shouldn’t be relevant here (I think it’s safe to presume you weren’t using it…)
NPM doesn’t always cleanup/fix things on attempts to remove and/or reinstall once this issue has occurred; deleting the folder and then installing is more reliable.

In any case it sounds like you’re good to go for now!

ScottFreeCode on Oct 7, 2017

@sierranevadan

I’m not too familiar with the internals of mocha, but one potential fix would be to move the code in ./options to mocha/bin/mocha (and mocha/bin/_mocha ) so that there isn’t a relative import in bin/mocha .

Where this is caused by the symlinks having been transformed into regular files (the only confirmed cause so far that I’m aware of), it would just error on the next relative import – it’s not actually the options module that’s at fault, but rather the fact that the files have effectively been transferred to and are running from the wrong location.

I’ve had the chance to confirm that this issue can result from using rsync with options that convert symlinks into regular files (and therefore, by extension, anything else that does the same). I’ve been thinking about how to address it.

So far I haven’t come up with anything I think is a good idea. I’ve thought of a fairly wide variety of bad ones. Potential solutions vary in robustness, in helpfulness and in the assumptions they make about the package manager that’s installing Mocha; I haven’t come up with any that are more than marginally helpful, are robust and don’t make any assumptions.

One thing that has crossed my mind is that this potentially affects any (especially locally installed) CLI Node program (excepting Windows-only ones, if there even are any of those). Mocha might get hit by it more than others due to greater popularity, but to really resolve the issue in general you’d have to either have every Node CLI program handle this in some way or else change NPM’s use of symlinks. So I wonder: is there some expected convention that other programs follow and Mocha just happens to be out of the ordinary for missing it? Or is this something that arguably ought to be fixed in NPM instead of every CLI program having to come up with a way to handle it?

ScottFreeCode on Jul 5, 2017