Home → Questions →

NPM cache

• Edit

Michael Huensch

26 Sep, 2014 09:39 PM

I am trying to run a npm install

     npm install Web/Client --prefix Web/Client

and getting the following error:

Creating library C:\projects\foogenda\Web\Client\node_modules\mongoose\node_modules\mongodb\node_modules\bson\build\Release\bson.lib and object C:\projects\foogenda\Web\Client\node_modules\mongoose\node_modules\mongodb\node_modules\bson\build\Release\bson.exp
112 Generating code
113 Finished generating code
114 bson.vcxproj -> C:\projects\foogenda\Web\Client\node_modules\mongoose\node_modules\mongodb\node_modules\bson\build\Release\\bson.node
115npm ERR! EEXIST, open 'C:\Users\appveyor\AppData\Roaming\npm-cache\ce226193-m-cache-lodash-2-4-1-package-tgz.lock'
116File exists: C:\Users\appveyor\AppData\Roaming\npm-cache\ce226193-m-cache-lodash-2-4-1-package-tgz.lock
117Move it away, and try again.
118
119npm ERR! System Windows_NT 6.2.9200
120npm ERR! command "C:\\Program Files (x86)\\nodejs\\\\node.exe" "C:\\Program Files (x86)\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install" "Web/Client" "--prefix" "Web/Client"
121npm ERR! cwd C:\projects\foogenda
122npm ERR! node -v v0.10.32
123npm ERR! npm -v 1.4.28
124npm ERR! path C:\Users\appveyor\AppData\Roaming\npm-cache\ce226193-m-cache-lodash-2-4-1-package-tgz.lock
125npm ERR! code EEXIST
126npm ERR! errno 47
127Command exited with code 47

When I have seen similar issues locally it usually means that the npm cache is corrupt. I don't see any way to remove this cache (or even use a different one), is there something that I am missing?

1. Support Staff 1 Posted by Feodor Fitsner on 26 Sep, 2014 11:42 PM

   

   Have you tried removing the contents of C:\Users\appveyor\AppData\Roaming\npm-cache\ folder as part of your build?

   -Feodor

   • Edit

2. 2 Posted by Michael Huensch on 30 Sep, 2014 01:40 AM

   

   For other people having this problem I was able to replicate this problem locally by first:
   1. Removing all the packages installed locally in my project with npm
   2. Clearing out the npm cache

   The problem is that npm by default puts its cache in: C:\Users\<user>\AppData\Roaming\npm-cache (as seen above) and this is a problem when the path gets over a certain length because windows has a restriction on the path length that other operating systems don't. As a result the solution is to configure the base cache path for the current user to something much shorter. In my current yml I added the following:

   install:
     - md C:\npm-cache
     - npm config set cache C:\npm-cache
     .....
     - npm install

   This changes the path for the cache to a folder to the newly created npm-cache folder created at the root.

   Feodor: you may want to set this to the default for the build instance as the error message given by npm is quite confusing and hard to track down as its Windows specific and doing so may save future users of node.js/npm a lot of time.

   • Edit

3. 3 Posted by Michael Huensch on 30 Sep, 2014 03:50 AM

   

   After I fixed this initially, the problem came back. I had to cache the resulting npm cache folder. Obviously I missed something.

   • Edit

4. Support Staff 4 Posted by Feodor Fitsner on 30 Sep, 2014 04:16 AM

   

   Oh, thanks for investigating that. What was the package giving very long paths?

   • Edit

5. 5 Posted by Michael Huensch on 30 Sep, 2014 08:05 PM

   

   Its something that requires lodash. However while the paths are long, I'm not sure it's acutally the problem now because I started getting the same error at:

    'C:\npm-cache\ed2e4713-m-cache-lodash-2-4-1-package-tgz.lock'

   It fixed it for a while, but now its back. Its something in the process that is locking the file, because if I catch the error in a powershell script and re-run in the catch its still locked. However, if I cache the npm cache folder between builds, run the build and then cancel it before it can error -- the error goes away.

   However, once I set the cache folder to something shorter locally, I have been unable to reproduce the error on my machine. This seems to indicate to me that there were actually two problems.

   1. the folder path being too long.
   2. something locking the file.

   Its really starting to annoy me =P

   • Edit

6. 6 Posted by Ray Tiley on 01 Oct, 2014 12:52 AM

   

   We are seeing this same issue on ember-cli build: http://help.appveyor.com/discussions/questions/534-npm-cache

   • Edit

7. 7 Posted by Ray Tiley on 01 Oct, 2014 12:54 AM

   

   Ugh, wrong link: https://ci.appveyor.com/project/stefanpenner/ember-cli

   • Edit

8. Support Staff 8 Posted by Feodor Fitsner on 01 Oct, 2014 02:49 AM

   

   Is it like this "lock" issue started at some point. Could it be related to node.js update on build workers (the current on is 0.10.32)? Have you tried running on previous version of node?

   Node.js version could be switched with the following PS line:

   install:
     - ps: Install-Product node <version> [bitness]
   

   for example:

   install:
     - ps: Install-Product node 0.10.31 x86
   

   • Edit

9. 9 Posted by Michael Huensch on 01 Oct, 2014 03:32 AM

   

   Yes, I have tried older versions (as far back as 9) and newer versions (as far as 11) and the issue still occurs. Additionally, I have also tried newer versions of NPM as a stand alone (up to 2.1) and no change. I have not tried older versions.

   Again, just to be clear, I don't see the problems locally running the same versions of node and npm as Appveyor (not that I think that rules anything out).

   I'm still investigating though, and I will let you know if I find anything else.

   • Edit

10. 10 Posted by Michael Huensch on 01 Oct, 2014 07:06 AM

    

    I have built several times successfully now using

    - ps: Install-Product node 0.10.30 x86

    at the beginning of my script. I'm still not confident that this fixes the issue, but so far so good.

    Also, I cant remember if my previous downgraded builds were done while also using the full path. I will try that again at some point soon to confirm

    • Edit

11. 11 Posted by Michael Huensch on 01 Oct, 2014 08:30 PM

    

    I finally got a totally green build and I can confirm that its all been working well with Node.js 10.30. I even removed the script that relocated the npm-cache to C:\npm-cache - and it still worked.

    I am going to leave the setting in my own build script (just in case), but I built several times without it - just for giggles - and it was fine.

    I'm curious if Ray Tiley has the same experience.

    • Edit

12. Support Staff 12 Posted by Feodor Fitsner on 01 Oct, 2014 08:33 PM

    

    That's great, thanks for the update!

    • Edit

13. 13 Posted by Nadeem Sarwar on 03 Nov, 2014 02:56 PM

    

    Posted by Michael Huensch on Oct 01, 2014 @ 09:30 PM

    Michael Huensch's Avatar
    I finally got a totally green build and I can confirm that its all been working well with Node.js 10.30. I even removed the script that relocated the npm-cache to C:\npm-cache - and it still worked.

    I am going to leave the setting in my own build script (just in case), but I built several times without it - just for giggles - and it was fine.

    I'm curious if Ray Tiley has the same experience.

    ======================================

    Hi Michael,

    Can you explain what you did?

    What does "I finally got a totally green build" mean?

    Is that the solution (so far, so good) - a totally green build?

    How does one get a totally green build please, thanks.

    deemyboy

    • Edit

14. Support Staff 14 Posted by Feodor Fitsner on 13 Jan, 2015 12:44 AM

    

    Hi guys,

    If you are still experiencing this issue. Apparently, these "lock" issues are mostly fixed with the latest npm 2.0.

    These two simple command allow installing npm 2.0:

    npm -g install npm@2
    set PATH=%APPDATA%\npm;%PATH%
    

    • Edit

15. Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 01:53 AM.