Error: Cannot find module '../lib/cli'

[ghost]

I am using eslint v3.3.1 with Sublime text 3 to develop my react web app. Currently I encounter an error say :

Error: Cannot find module '../lib/cli'
    at Function.Module._resolveFilename (module.js:455:15)
    at Function.Module._load (module.js:403:25)
    at Module.require (module.js:483:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/Users/Welly/Dropbox/GitHub/react-universal-starter/node_modules/.bin/eslint:29:11)
    at Module._compile (module.js:556:32)
    at Object.Module._extensions..js (module.js:565:10)
    at Module.load (module.js:473:32)
    at tryModuleLoad (module.js:432:12)
    at Function.Module._load (module.js:424:3) 

And when I remove and re-install node_modules, this error seems to be solved, but next time I launch my code editor this error occurs again, does anyone has this problem?

Here's my .eslintrc :

{
  "parser": "babel-eslint",
  "extends": "airbnb",
  "plugins": [
    "react"
  ],
  "env": {
    "es6": true,
    "browser": true,
    "node": true
  },
  "rules": {
    "global-require": 0,
    "no-underscore-dangle": 0,
    "no-console": 0,
    "react/jsx-filename-extension": [1, { "extensions": [".js", ".jsx"] }]
  },
  "globals": {
    "__DEV__": true,
    "webpackIsomorphicTools": true
  }
}

[kaicataldo]

Hey, could you let us know where you're getting this output from? Is that from the command line or some sort of log in ST3?

[ghost]

@kaicataldo This is from ST3 debug log

[mysticatea]

Is this reproduced outside of Dropbox?

[ghost]

@mysticatea Yes, I have tried to move the project outside of Dropbox and the error still occurs.

[mysticatea]

Ah, sorry.
My intention is "could you confirm that Dropbox sync behavior doesn't break installed eslint files?".
I don't think eslint throws that error before someone breaks the code of eslint.

[ghost]

Hi @mysticatea All of the files in my local dropbox folder, I don't know why those files will be broken?

[mysticatea]

I'm not sure why those files will be broken, too.
It's the reason I asked: "Is this reproduced outside of Dropbox?".

If it's reproduced outside of Dropbox, I don't have another idea. :/

[kaicataldo]

I actually found a reproduction case for this (totally coincidentally, while working on a personal project). I get the exact same error when I copy a project directory (including its node_modules) and try to run the local ESLint installation from the copied directory. rm -rfing node_modules and npm i again in the copied directory fixes it.

Sounds like maybe something Dropbox is doing is causing a similar issue?

@wellyshen Can you confirm this does or doesn't happen when the project directory is outside of your Dropbox directory?

[ghost]

@kaicataldo Yes, I am doing the same thing, I move my project out of my Dropbox folder. And reinstall the node_modules. Now I am observe if the error will happen or not.

[nzakas]

@ghost does that fix your problem?

[vitorbal]

ping @ghost, any chance you could give us an update if your problem is fixed? Thanks!

[vitorbal]

Closing, as there has been no updates from the author in more than 40 days.

[rschamp]

This happens to me and my team occasionally — the root cause seems to be that somewhere along the line node_modules/.bin/eslint has become a real file, a copy of bin/eslint.js. Then when you run eslint, it tries to require('../lib/cli') relative to node_modules/.bin/ which crashes with this error. Uninstalling and reinstalling eslint fixes the issue, as it fixes .bin/eslint to be a symlink again, but I wonder if some combination of dependencies causes this to happen?

This just happened to me while working on this repo (i.e. running npm install and npm test there): https://github.com/LLK/eslint-config-scratch. I'm using npm v3.10.8.

[cyrus-and]

The point is that Dropbox doesn't properly sync symlinks. So if npm install has been executed on computer A and computer B receives node_modules via Dropbox, then computer B will end up with a broken node_modules folder where symlinks have been replaced with regular copies.

This doesn't happen with ESLint only, it impacts every Node.js module which provides at least one executable which relies on relative paths.

Possible solutions:

• delete such modules only (e.g., rm -fr node_modules/eslint) then npm install again;

• manually symlink the executables (e.g., ln -s ../eslint/bin/eslint.js node_modules/.bin/eslint).

This thing is incredibly annoying...

[rschamp]

Yes, it does occur with other modules. After I posted that, the same thing happened with tap. The thing is that I only use Dropbox for backup, I don't use the syncing behavior on multiple computers, and yet Dropbox apparently destroys the symlinks even then.

Even more annoying to me after some Googling to see that Dropbox has had this issue for years and years. Ironic because a lot of their user base must be developers.