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

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

Closed
mikeerickson opened this issue Aug 6, 2016 · 25 comments
Closed

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

mikeerickson opened this issue Aug 6, 2016 · 25 comments
Labels
type: bug a defect, confirmed by a maintainer

Comments

@mikeerickson
Copy link

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)
@gurdiga
Copy link

gurdiga commented Aug 7, 2016

Hey @mikeerickson! 🙂

I have tried to reproduce this with the current npm version and failed. 😑

I’m wondering if you see anything any differences between my scenario and yours, and maybe that would point us what could be wrong here. 🤓

@mikeerickson
Copy link
Author

@gurdiga Hey there... I will perform the exact same tasks here to see what happens. I know I have done this before reporting, but I will start a new project again and record as you have done so we can compare. Thx for taking the time to do this, something is surely interfering?

mse

@mikeerickson
Copy link
Author

@gurdiga of course, when I follow this approach from scratch, all works. I will see if I can track down the issue in my current project. This for efforts, will close for now but if I can reproduce, I will reopen this ticket.

@damienromito
Copy link

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.

@mikeerickson
Copy link
Author

@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

@ScottFreeCode
Copy link
Contributor

If anyone can figure out what triggers the options module to go missing in the first place, please let us know.

@mikeerickson
Copy link
Author

@ScottFreeCode I have spent quite some time trying to track it down with zero success. I have had it happen quite often, but haven't been able to find the root cause. Certainly happens frequently enough to warrant an alias reinstall when it occurs :-(

@MaitreyaBuddha
Copy link

I have a repo sync'd via dropbox on two computers (because.. well.. don't ask). The new sync gets this error while the old sync does not. If I run npm uninstall -D mocha && npm i -D mocha on the new computer, it fixes that computer. However, it busts the old one back to this issue. This isn't blocking me so I'm not gonna throw myself at it too hard, but I have a stable repro if anyone wants me to do some tests/checks.

@jervisfm
Copy link

jervisfm commented Feb 1, 2017

I had done a npm install on a new project and ran into this issue when doing npm test.

Suggested workaround of removing node_modules directory and doing npm install again worked for me.

@mikeerickson
Copy link
Author

@jervisfm I receive this issue randomly (never taken the to really debug it much).

However, it happens frequently enough that I created an alias

alias fix-mocha="npm uni -D mocha && npm i -D mocha" 

I just run this whenever I see the error message

@nathanpeck
Copy link

I regularly experience this when I copy and paste a node_modules folder or move it from one place to another. Something in mocha is hardcoded so that when you move the node_modules folder mocha stops working until you uninstall and reinstall mocha.

Pretty bad design imho.

@Munter
Copy link
Contributor

Munter commented Feb 1, 2017

Can we get done data here so we can track it down?

Node version, npm version, mocha version, operating system

@nathanpeck since you seem to have a consistent reproduction, could you create a test case or help us out with some more details?

@CelsoSantos
Copy link

I believe this may be due to spaces on the path.

I can run mocha by running npm uni -D mocha && npm i -D mocha and then npm test but it will always fail the following execution with that error

@mikeerickson
Copy link
Author

@Munter FWIW, I have not seen this happen in quite some time. So many variables have changed since then, hard to say what the "real" cause has been.

@mikeerickson
Copy link
Author

@Munter If I am able to reproduce, I will let you know. I am doing a lot of testing at the moment on a current project, thus I would expect at some point for this to happen again.

@CelsoSantos
Copy link

Oh, I should have mentioned that.

I'm using mocha 3.2.0 and node 6.7.0.

@sierranevadan
Copy link

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.

@hovissimo
Copy link

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

@drazisil drazisil added type: bug a defect, confirmed by a maintainer unconfirmed labels Apr 1, 2017
@ankur-anand
Copy link

The issue with Symlinks is definitely causing the issue updated the detailed here.
#2582 (comment)

@ScottFreeCode
Copy link
Contributor

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

@schatekar
Copy link

I have even stranger behaviour. I have a project where I use script section of package.json to define my test command. This looks like the below

  "scripts": {
    "test": "MODE=test mocha -r ts-node/register test/**/*.ts --timeout 10000"
  },

This works absolutely fine. Then I started working on a new project where I have exactly the same setup but kept getting this error to do with missing options module. I first checked if the node_modules/.bin contains a file named options or options.js. Both projects do not have this file and still, one project does not complain and other complains.

I changed the test script of the complaining project to explicitly point to mocha in node_modules/.bin folder by changing the script to the below

  "scripts": {
    "test": "MODE=test node_modules/.bin/mocha -r ts-node/register test/**/*.ts --timeout 10000"
  },

Then I noticed that the mocha install directory node_modules/mocha has a bin directory that contains a options.js file. So I changed my script to refer to mocha from there like the below

  "scripts": {
    "test": "MODE=test node_modules/mocha/bin/mocha -r ts-node/register test/**/*.ts --timeout 10000"
  },

This makes the error go away. But I am not sure why the first project still works without any options file in nide_modules/.bin directoy.

@ScottFreeCode
Copy link
Contributor

@schatekar NPM creates node_modules/.bin/mocha as a symlink to node_modules/mocha/bin/mocha. As long as it's a symlink, when you node_modules/.bin/mocha (for which mocha in a scripts entry is shorthand) it actually runs node_modules/mocha/bin/mocha. Most likely, however, you copied the project that's not working, or at least its node_modules folder, in a way that converted the symlink into a copy of the node_modules/mocha/bin/mocha file, resulting in it running in node_modules/.bin, where it won't find other Mocha files (./options.js happens to be the first one, but the issue would be the same no matter which other Mocha files it uses and no matter the order in which it uses them). The most reliable way to fix the faulty project is to delete node_modules and npm i again.

@schatekar
Copy link

@ScottFreeCode I should have been more careful while describing what I did. I did not literally copy the folder from the working project to the new project. I looked at the package.json of the working project and installed all the modules from there into the new project. I also uninstalled and re-installed mocha couple of times while I was following the suggestions on this thread.

@schatekar
Copy link

After I wrote the above comment, I thought maybe I should go back and check the symlinks. Symlinks where not there (may be an npm bug??). I manually created the symlinks and it all works fine.

@ScottFreeCode
Copy link
Contributor

👍 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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug a defect, confirmed by a maintainer
Projects
None yet
Development

No branches or pull requests