I have a serverless nodejs project which was working just fine. Did not touch it for a week, wanted to re-deploy it and now I'm greeted with the following errors:
1) EPERM: operation not permitted, scandir ‘D:\GIT\awesome.build\node_modules’
2) EEXIST: file already exists, symlink ‘D:\GIT\awesome\node_modules’ -> ‘D:\GIT\awesome.build\node_modules’
First off I get the first error. If I try for a second time I get the second one. If I delete .build I'm back to receiving the first.
I know that during the idle week I did get the spring Windows update.
Windows 10 17134.48
NPM 6.1.0
Nodejs 8.11.1
Any ideas what could be causing this?
Updated Answer
We've identified and found the issue relating to this. We have published a new NPM module specifically with this fix and created a PR on the original plugin (but he hasn't updated it in ages)
Fixed Version
https://www.npmjs.com/package/#hewmen/serverless-plugin-typescript
Original Answer:
We're running into the exact same issue. Multiple serverless projects, multiple computers. We've tried different node versions as well. Completely wiping fetched repo and redoing it. We've tried using elevated consoles. No idea what's going on, but we're getting that exact same error on all our stuff across 3 different machines.
Current suspicion is Windows did an update recently that hosed it.. but I figured we'd see more info on it.
However, we did find a workaround for this.
Delete your current '.build' and '.serverless' folders inside the root project area
In command prompt, run 'sls package' and let it fail with the same error
Manually copy over 'node_modules' and 'package.json' from the root directory into the .build folder (delete the ones in there). This won't cause the error saying the .build directory already exists which you might have seen fighting this.
In command prompt, run 'sls deploy' (or 'sls package' if you only want to package)
Not ideal... but it got us deploying again until we figure out the real issue.
The issue seems to be in the way the symbolic link is created for node_modules inside the '.build' folder. It's linking a directory, but seems to be treating it as a file all of a sudden for whatever reason. In windows if you use "mklink" without the '/D' option on a directory, it will give you the same result we see in the '.build' folder. If you do the mklink /D - you don't have this issue.
This is why our current suspicion is a Windows update. Because everything was working perfectly fine, then all projects across all our Windows PCs stopped. We've rolled back our repos to stuff we've successfully deployed, and no issues. We've attempted to re-deploy projects we haven't touched in months, same issue.
It's very annoying to say the least. I will update this if we find out what's wrong.
Related
I am trying to delete the node modules folder from my project so that I can rerun npm i as there were errors when I was running my npm scripts (I think node_modules corrupted), but I don't seem to be able to.
I've tried:
Deleting via right clicking in Windows explorer. This just doesn't do anything.
In VS Code right clicking and selecting 'Delete Node Modules', which produces the following message:
I think the node modules file has corrupted - there only seems to be 3 folders in there, all of which I can't delete.
If I run npm i I get the following:
Try to reboot windows with SAFE MOOD.
I face the same issue on windows 10. I could delete it when I have been in a safe mood on windows.
Don't know really an issue on windows or my hard drive.
I have a create-react-app project that works well. However, if I let it sit for a couple days—without making any changes—it always breaks, with the error
package.json » eslint-config-react-app/jest#overrides[0]:
Environment key "jest/globals" is unknown
I'm convinced this is because desktop.ini files get created, and somehow they mess up the loading process of the dependencies. The problem gets fixed if I delete the whole node_modules folder and reinstall it using npm install. But the newly installed dependencies only last a couple of days (until the new desktop.ini files get regenerated) before they again break.
I've tried to stop windows from producing the desktop.ini files using the registry, but windows didn't listen (I run Windows 11). I've also seen that it is not recommended to delete/suppress these files.
Has anyone dealt with this issue? Are there any manageable workarounds?
This is a weird question. I'm converting an existing site to Gatsby (a Node package I installed with npm i -g gatsby-cli), and when I run gatsby develop I get an error:
Error: ENOENT: no such file or directory, stat '/home/me/.steampath'
Now the backstory here is that on Linux Steam deliberately installs a bad symbolic link called .steampath for some stupid reason. But what I can't understand is why/how running a specific Node application (Gatsby) could result in this error, which has nothing to do with my project or Gatsby ... when running other Node apps doesn't.
I've done a grep through my project directory: steam doesn't appear in any file. Similarly I grepped my environment (env | grep steam), and there's no environmental variable pointing to that file.
So can anyone answer: why does running Gatsby cause an error in a completely unrelated symbolic link sitting outside the project in my home folder?
I imagine Gatsby must be running some sort of system command, but I can't even imagine what it could run that would scan my home directory and complain about broken symbolic links.
P.S. This error comes at the end, after other errors, so it doesn't look like it's causing gatsby develop to fail so much as it's reporting the error at the end.
P.P.S. Removing the bad symlink does fix things (although I don't know what Steam will think) ... but then I get another error about another broken symlink in my home folder (I can't blame Steam for that one). So something Node/Gatsby is doing is resulting in a scan of my home dir, and a complaint about any broken symlinks found!
Once all broken symlinks are removed Gatsby works normally. So bizarre!
An answer to your question can be found here
I also had this issue today, it surfaced when one of my JS imports was
not installed (redux). Adding the dependency fixed the issue. When the
dependency was absent from the node_modules directory, something (i
didn't dig far enough) would stat my entire home directory. With the
dependency present the ~ directory was left alone.
It's related to the node resolution algorithm and although more information is not given, I believe it may be related to this
I was also quite worried when I initially saw this error.
I'm building a .Net Core application using Angular for my client-side code. For the most part, I'm using the default template that is included in VS 2017. For whatever reason, VS is making my node_modules folder read only. Before I was able to install packages via command line in the directory that holds my client side code as well as my package.json file and my node_modules folder. Before I was able to do this, but now it is defaulting the folder to read only which is invaliding all of my npm commands. I've verified that this is the case because I can remove the read only attribute via windows explorer and then run any of my commands like npm install.
Has anyone else encountered this before? If so, what did you do to resolve this?
Thanks!
Okay, I found the answer. VS puts a lock on the node_modules folder while it is running.
So, I guess for now if you need to add packages just close VS first.
Usually when I do 'npm install' inside my application directory, bunch of npm libraries files gets generated inside node_modules folder which is expected.
Today suddenly I started seeing many files getting generated inside application directory and outside node_modules.
Did anyone face this issue ? and if yes - any workaround ? Screenshot attached. Lot's of .cmd file, don't know why they are here.
Edit your c:\Users{username}.npmrc and remove the prefix.
I had the same issue, and was able to resolve this by completely uninstalling + re-installing Node/npm:
How to completely remove node.js from Windows