no such file or directory, rename dezalgo #420
Comments
|
Same thing happens to me. |
|
Same issue here. Installing |
|
Same here. It just works when is installed globally. |
|
+1 |
1 similar comment
|
+1 |
|
This is due to an old version of |
|
@raineorshine did not help me.
|
|
@raineorshine Yeah right after i posted i thought i was on npm 5.6 but i was actually on 4.6.1. What was confusing me is when I went npm -v it showed 5.6 but I noticed i was on 4.6.1 in my package.json. Anyway I upticked to the latest npm in my package.json and it solved my problem. |
|
@reft I was made aware that |
|
@raineorshine I just test Is it going to be published as a definitive release? |
|
@franher It will be published as v3, but the intention is to include the other breaking changes. I am watching the repo and doing fixes where I can, but there are currently no active developers on npm-check-updates. |
As a workaround I've been using; $ npx npm-check-updates -e 1Love |
It appears that the intention of including `npm-check-updates` in this repository was to provide an easy way to update dependent packages from the console. This was originally introduced in [Ref 0]. Unfortunately, the `npm-check-updates` package has an explicit dependency on `npm@3`, which means that it includes the entire `npm` in its `node_modules`. I originally observed this when analyzing the test failures in [Ref 1] and [Ref 2] which indicated (in its npm error) that the npm version was v3.10.10. The explanation for this is relatively straight-forward: Older versions of npm uses an nested tree of `node_modules` directories while newer versions hoist `node_modules` (i.e. flatten) to the highest location possible and only nesting dependencies to meet conflicting version constraints. Unfortunately, that means that once `npm@3` was installed by the newer `npm@5` as a dependency of `npm-check-updates`, it was hoisted to the top-level `node_modules` directory, exposing `npm@3` to `npm-scripts` which directly call `npm` commands on the nested packages, as is done on this monorepo (with, for example the `postinstall` script which runs `npm run compile` in each of the server middleware packages). :face_palm: Overall, this package doesn't seem to provide enough value for us to continue to include it, especially since we have Renovate - coupled with the same information being available from `npm outdated` and `npm update` commands. I'm not sure why we would want to install newer versions than our "package.json" allows. Futhermore, looking at the issue tracker on `npm-check-updates`, I'm assuming this is the reason I've seen "`dezalgo`" install errors [Ref 3] on this repository recently and _possibly_ even a bizarrely corrupted npm cache I encountered recently (though admittedly, that could be a stretch). See also: [Ref 4]. [Ref 0]: d7ca07f7 [Ref 1]: https://circleci.com/gh/apollographql/apollo-server/1915 [Ref 2]: https://app.netlify.com/sites/apollo-server-docs/deploys/5acdd3b7 [Ref 3]: raineorshine/npm-check-updates#420 [Ref 4]: raineorshine/npm-check-updates#423
It appears that the intention of including `npm-check-updates` in this repository was to provide an easy way to update dependent packages from the console. This was originally introduced in [Ref 0]. Unfortunately, the `npm-check-updates` package has an explicit dependency on `npm@3`, which means that it includes the entire `npm` in its `node_modules`. I originally observed this when analyzing the test failures in [Ref 1] and [Ref 2] which indicated (in its npm error) that the npm version was v3.10.10. The explanation for this is relatively straight-forward: Older versions of npm uses an nested tree of `node_modules` directories while newer versions hoist `node_modules` (i.e. flatten) to the highest location possible and only nesting dependencies to meet conflicting version constraints. Unfortunately, that means that once `npm@3` was installed by the newer `npm@5` as a dependency of `npm-check-updates`, it was hoisted to the top-level `node_modules` directory, exposing `npm@3` to `npm-scripts` which directly call `npm` commands on the nested packages, as is done on this monorepo (with, for example the `postinstall` script which runs `npm run compile` in each of the server middleware packages). :face_palm: Overall, this package doesn't seem to provide enough value for us to continue to include it, especially since we have Renovate - coupled with the same information being available from `npm outdated` and `npm update` commands. I'm not sure why we would want to install newer versions than our "package.json" allows. Futhermore, looking at the issue tracker on `npm-check-updates`, I'm assuming this is the reason I've seen "`dezalgo`" install errors [Ref 3] on this repository recently and _possibly_ even a bizarrely corrupted npm cache I encountered recently (though admittedly, that could be a stretch). See also: [Ref 4]. [Ref 0]: d7ca07f7 [Ref 1]: https://circleci.com/gh/apollographql/apollo-server/1915 [Ref 2]: https://app.netlify.com/sites/apollo-server-docs/deploys/5acdd3b7 [Ref 3]: raineorshine/npm-check-updates#420 [Ref 4]: raineorshine/npm-check-updates#423
|
I had this issue too using npm v5.6.0, upgraded to 6.0.0 and now every installation works fine. run |
|
whats so bad about |
|
Fixed in the upcoming release |
Received followign error today only.
npm ERR! path //development/node_modules/dezalgo
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall rename
npm ERR! enoent ENOENT: no such file or directory, rename '//node_modules/npm/node_modules/dezalgo' -> '//node_modules/npm/node_modules/.dezalgo.DELETE'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent
The text was updated successfully, but these errors were encountered: