2017-06-02 29 views
1

最近、npmをv5.0.1(4の最後のバージョンから)に更新しましたが、一般的に致命的です。NPM v5.0.1のアップグレード後に 'fs.realpath'モジュールが見つかりません

とにかく、私はこの時点で立ち往生しています。この同じアプリケーションは、MacOSで正常に動作しますが、Ubuntuの16.04.2 LTSにそれが与える

module.js:471 
    throw err; 
    ^

Error: Cannot find module 'fs.realpath' 
    at Function.Module._resolveFilename (module.js:469:15) 
    at Function.Module._load (module.js:417:25) 
    at Module.require (module.js:497:17) 
    at require (internal/module.js:20:19) 
    at Object.<anonymous> (/home/user/back/node_modules/glob/glob.js:44:10) 
    at Module._compile (module.js:570:32) 
    at Object.Module._extensions..js (module.js:579:10) 
    at Module.load (module.js:487:32) 
    at tryModuleLoad (module.js:446:12) 
    at Function.Module._load (module.js:438:3) 
npm ERR! code ELIFECYCLE 
npm ERR! errno 1 

注:私は実行しようとする任意のNode.jsアプリケーションが細かい「NPMインストール」が、出力を開始したときに完了します上記のエラー。

両方のマシンでnode_modulesディレクトリを削除して再実行したところ、macOsは正常に動作し、Ubuntuは失敗します。

node -v: v6.10.3 

...両方のマシン用です。

npm -v: 5.0.1 

それはまた、私は、ログ(/home/user/.npm/_logs/2017-06-02T23_19_59_859Z-debug.log)を見て提案するが、それはさらに少ない情報を提供します。

13 info lifecycle [email protected]~start: Failed to exec start script 
14 verbose stack Error: [email protected] start: `tsc && npm run moveassets && NODE_ENV=production forever start -a -l back.log -e back-err.log ./build/www.js ` 
14 verbose stack Exit status 1 
14 verbose stack  at EventEmitter.<anonymous> (/usr/lib/node_modules/npm/lib/utils/lifecycle.js:283:16) 
14 verbose stack  at emitTwo (events.js:106:13) 
14 verbose stack  at EventEmitter.emit (events.js:191:7) 
14 verbose stack  at ChildProcess.<anonymous> (/usr/lib/node_modules/npm/lib/utils/spawn.js:40:14) 
14 verbose stack  at emitTwo (events.js:106:13) 
14 verbose stack  at ChildProcess.emit (events.js:191:7) 
14 verbose stack  at maybeClose (internal/child_process.js:886:16) 
14 verbose stack  at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5) 

注意をバージョン5.0.1にNPMの運命的なアップグレードされるまで、それは両方のマシンでうまく働いていること:ここでエラーが報告されたのです。それはOSのバージョンではないようです

が、MacOSのは、パッケージ・lock.jsonファイルを生成していましたし、Ubuntuはそれを消費し、そのことからインストール基づかたという事実:

PROBLEM ISOLATED WITH UPDATE 。下記のように、ファイルとrm -r node_modulesフォルダを削除すると、インストールすることができ、すべて正常に動作します(しかし、明らかにバージョンロックの利点は得られません)。

NPMの現行バージョンのバグだと思います。十分に公正な、それは大きな変化であり、完了すると良い機能になります。あなた

rm -rf node_modules 

が再び

npm install 

を行う場合

+0

あなたは 'NPMキャッシュclean'をやって試してみましたか? – Joe

+0

Heh - NPM v5.0.1で実行します。これは、キャッシュが完全であることを伝えてくれるので、もう一度それをきれいにする必要はありません。これは私がすでに見てきたが、真実ではない。 'npm cache clean --force'を実行しても問題は解決できますが、これは役に立ちません。 v5.0.1にアップグレードしていない場合は、それをお勧めします。 GitHubの問題リストをチェックしてください。それは素晴らしいことではありません。 – WillyC

答えて

5

、それが動作します。

注:npmロックファイルも削除しました。

更新:
(考慮して、コメントを取って)

rm -rf node_modules 
rm package-lock.json 
npm install 
+0

NPMロックファイルとは、 'package-lock.json'を意味しますか?もしそうなら、はい、私はそれを行うことでそれを過ぎ去ることができることを発見しました。このファイルは、コミットシステムとターゲットシステム(私が正しく理解している場合)の間のバージョンの等価性を保証するもので、明らかにそれを実行していません。私はそれが現時点でNPM v5のバグだと思います。機能のためには良いアイデアだからうまくいけばそれはうまくいきます! – WillyC

+0

私はあなたが特定のファイルを述べるためにあなたの答えを更新すべきだと思うが、実際にはこれを過ぎてしまうだろう! – WillyC

+1

これを読んだ人には、パッケージロックファイルが存在する場合、npmをインストールしたことのない最新のNPMバージョンでこれを追加するだけです。私は決してそれをチェックインせず、npmのインストール操作を実行する前に削除します。 npmが更新されるたびに、私は希望から再びそれを試して、いつも失敗します。アイロニーはファイルをチェックインするように指示しているので、あなたのプロジェクトが単純ではない場合、ほぼ一定の運命を引き起こします。 – WillyC

関連する問題