Solving the 'npm WARN saveError ENOENT: no such file or directory, open '/Users/<username>/package.json'' error - npm

I'm a newbie so please include links to URLs or explain terminologies so I can understand.
I've managed to install 'npm' on a Mac OS (10.13.3) via the terminal, and have installed some packages like SASS using it.
I'm now trying to install sass-mq using npm. I think I've managed to install it, but I'd like a second opinion on what I might have done that was incomplete, or wrong while doing it.
Initially, following the instructions on the sass-mq Github page, I was trying to use:
npm install sass-mq --save
which gave me this error:
npm WARN saveError ENOENT: no such file or directory, open '/Users/<username>/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/Users/<username>/package.json'
npm WARN <username> No description
npm WARN <username> No repository field.
npm WARN <username> No README data
npm WARN <username> No license field.
+ sass-mq#5.0.0
updated 1 package and audited 1 package in 1.67s
found 0 vulnerabilities
Looking around, I realised I'm meant to be using
npm init
..before typing my 'install sass-mq --save' command.
Cool, done that. Next error was this:
package name: (nikhil) sass-mq
version: (1.0.0)
description:
entry point: (index.js)
test command:
git repository:
keywords:
author:
license: (ISC)
About to write to /Users/nikhil/package.json:
{
"name": "sass-mq",
"version": "1.0.0",
"description": "",
"main": "index.js",
"dependencies": {
"sass-mq": "^5.0.0"
},
"devDependencies": {},
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC"
}
Is this OK? (yes)
darwin:~ nikhil$ npm install sass-mq --save
npm ERR! code ENOSELF
npm ERR! Refusing to install package with name "sass-mq" under a package
**npm ERR! also called "sass-mq". Did you name your project the same
npm ERR! as the dependency you're installing?**
I think this is saying that I can't use 'sass-mq' (which is the name of the package, as the name of the local package (?) I'm installing into on my local machine. Some more info here.
So I simply tried this:
**package name: (sass-mq) media-queries-nikhil**
version: (1.0.0)
description:
git repository:
keywords:
author:
license: (ISC)
About to write to /Users/nikhil/package.json:
and it seems to have worked OK.
My question is: Is this the right way I should have done this? How do you usually do this?
Also, I get these warnings - is it OK to ignore them?
npm WARN media-queries-nikhil#1.0.0 No description
npm WARN media-queries-nikhil#1.0.0 No repository field.
I'm creating this question in part so others like me looking for the answer to a similar issue can find an explanation, instead of just commands they need to fix their issue. I found a few similar question-threads, but none that actually explained what was happening and why.
Thanks for reading, I really appreciate any help with this :)

TL;DR: The way you have done it is fine, and you needn't worry about those warnings.
For a more in-depth idea of why npm exists and how it works, read on.
npm stands for Node Package Manager. Packages are a fundamental part of the node ecosystem - they exist to allow you to use other people's solutions to common problems.
However, this can get very confusing, since, because this is an open source community, they are all being released at different times by different people. Also, two different packages that you use may actually be dependent on a third package that is completely unknown to you, and potentially they may even need different versions of that package.
As you can already see, this has the potential to get very messy.
npm helps you deal with these 'dependencies' in a way that is easier to manage and think about, however it is not essential to use npm - you can write a node app where you organise all these different files yourself. That's going to get very confusing, very quickly, however, so there's no real advantage in at least 99% of cases. There are also other package managers - personally I use yarn but they're all trying to do similar things, so that choice is mainly a matter of preference and outside the scope of this discussion.
So when you start a new project, you type npm init and this tells npm to make a file in your folder called package.json that is going to help you organise these dependencies. package.json will hold the information about your own app (which is a package in its own right) and also which packages you have told npm you are going to be using as dependencies in your own project. This is why it asks you all those questions about your package name and description, so that if you ever publish it, people will know who to contact, what it does, what version it is, etc.
It is only important to give this serious thought if you actually intend to publish your package, which is less likely in the case of a website, but very likely if you're making a library. However, as you've already discovered, packages are meant to have unique names, which is why you should call your package something personal to you, so you don't end up with a naming conflict like you did when you tried to name your package the same as a package you were later going to try to install.
So let's create our own package, and install our first dependency (which, remember, is just another package). I'm going to choose time-stamp as a dependency because it's nice and small.
First you will make your project directory. This is just an empty new directory. Let's call it ts. From inside the ts directory, type npm init into your terminal and answer its questions (although I usually just press return to them all,) then look inside the directory and you will see the package.json file. Open the file, and you will see all your package information. And currently that's it.
So now back to the command line and type npm install time-stamp. When it's finished thinking, open package.json again and you will see time-stamp referenced in the list of 'dependencies.' (As of npm 5 it is no longer necessary to use the --save option. npm now assumes this as default. What is the --save option for npm install?)
Back inside the directory, you will also see another file called package-lock.json and a directory called node_modules.
The node_modules directory will contain a directory called time-stamp and that holds all the code that makes time-stamp work. You probably don't need to look in here very often, but you can, and if you look inside the time-stamp directory you will see it has got its own package.json! Open it up and have a look, and there's all the information it needs to install itself. You'll note that it doesn't have any dependencies, but if it did, they would be installed in your node_modules with all of their dependencies as well... and their dependencies... and theirs... If you want to see this in action, try installing the testing framework 'jest. Again, just npm install jest.
Hopefully the whole thing's beginning to make a bit of sense, now...
The lock file is slightly more complicated. What it does is make sure that when you deploy your project onto a new system that you use exactly the same set of dependencies. It needs to do this because the way npm organises things can be dependent on latest release versions, etc, and it would be very annoying if you were to try to deploy your app and it didn't work because your dependencies were behaving in a different way from your development environment!
Having said all this, basically you can ignore it at this stage! It's an important part of npm, but you shouldn't edit it directly unless you really know what you're doing.
Once you have installed your dependency, you will be able to require or import it anywhere in your project, without having to worry about directing it to the correct path in your directory structure. Just require('time-stamp') and it will work just fine!
Finally, and well done for getting this far, it's worth mentioning global installation. Using the -g option - that is npm install time-stamp -g - means that the dependency will be installed in a central node_modules directory somewhere on your computer rather than in your project's node_modules folder. However, you will still need to link it to your project (so that it ends up as a dependency in your package.json) and you would do that by typing npm link time-stamp. Personally I like all my modules to be local to my project, but again this depends on your use-cases and to an extent personal preference.
What this all means is that the combination of your package.json and the lock file is a perfect representation of all the files in your node_modules, and this means that you don't need to have them in your git (or other repository.) You can pull your repository down to a new server, and all you have to do is type npm install and they'll be dragged down from the internet there and then. This becomes much more important when you have a large project, because of all the files involved in your dependencies, but it's a good habit to add 'node_modules' to your .gitignore from day one. But I'm starting to get off topic so maybe I should end here...
This is only intended to be a basic introduction, so I have kept it fairly simple, and I don't want to create an in-depth tutorial, but if you need clarification on any of the points I've made, feel free to comment and I'll make edits if I can!

npm WARN saveError ENOENT: no such file or directory, open '/Users/{username}/package.json'
You don't have a package.json > use npm init
You are in the wrong directory > cd to the folder where your package.json is, like so:
cd C://Dev/MySolution/MyWebProject
and then try again.
npm WARN media-queries-nikhil#1.0.0 No description
npm WARN media-queries-nikhil#1.0.0 No repository field.
Abulifa's answer explains that your project could be published as it's own npm package... In that scenario, these warnings would help warn that your package.json is missing some fields.
If you know you'll never publish as an npm package, and want to hide these warnings, add this to your package.json:
"description": "filling out this field to avoid warnings",
"repository": "not publishing",
"readme": "not publishing",
"license": "not publishing",

Run the following:
npm init -y
That will create the package.json file which you can edit later with proper information.
Reference: https://www.digitalocean.com/community/questions/npm-warn-saveerror-enoent-package-json-not-found

Issue:
npm install fails with below error
npm WARN saveError ENOENT: no such file or directory, open '.../package.json'' error
Cause
npm install will need package.json in the current directory you are in, which is missing.
Solution
Assume there are 2 directories:
C:\dir1_p\ <--------- package.json exists
C:\dir2\ <--------- package.json does not exist
cd C:\dir1_p\
npm intall <---------- PASS, since package.json is present
cd C:\dir2\
npm intall <---------- ERROR, since package.json is Not present (this was my problem)
So, are you in the correct directory when you did npm install?
Case 1: if you are in wrong directory, cd to a directory where package.json exists, then run npm install
Case 2: if you are in correct directory and you want to create a new package.json, then run npm init and press ENTER keys until it is completed, this will create package.json in current directory, now run npm install
Hope this helps someone.

The same issue occurred for me when running:
npm install -g #vue/cli
After much research and experimentation the only thing that worked instead was:
npm install -g #vue/cli#latest

You can't name your project equal the package name that you are trying to install.
Rename your project at the package json and try again or try npm init again and use another name.

One of the major problem could be that you are not at the root file were you should run npm install, make sure you are either at the client folder or the server side and not in some random files or the parent file that doesnt have package.json in them

close the project and reopen it, this will fix the issue

Related

Patching a NPM package locally with patch-package, not working

I'm working on a vue.js frontend, and I need to patch a package to fit the special needs of the app. The package I'm trying to patch is 'vue-youtube' (not that it really matters). I'm trying to patch it with patch-package (https://www.npmjs.com/package/patch-package)
So basically :
I edited locally the /node_modules/vue-youtube/src/vue-youtube.js to fit my needs
I did add the postinstall script in my package.json : "scripts": { "postinstall": "patch-package" }
I did npm install patch-package --save-dev
Then I ran npx patch-package vue-youtube
It did create a vue-youtube+1.4.0.patch file in a /patches folder with my modifications
BUT, my modifications are not seen. When I do npm run serve and launch my webapp, the package used is still the one not edited. I tried running npm install before, without success. When I go to the /node_modules/vue-youtube/dist/vue-youtube.js (thankfully it is a small package so it is readable), I can see that indeed my modifications have not been "compiled".
What am I missing here ? I feel like I have followed eveything in the patch-package npm page..
Thanks
EDIT : Still investigating.. few more informations/questions :
my patch name is patches/vue-youtube+1.4.0.patch
when i run npm ls vue-youtube it returns just one element : vue-youtube#1.4.0
in my package.json the dependency listed is "vue-youtube": "^1.4.0", should it be different ? should it mention that it needs to be patched ?
EDIT 2 : I realized that I am not editing the node_modules/vue-youtube/dist/vue-youtube.js, but the node_modules/vue-youtube/src/vue-youtube.
If you edit the files in the dist folder, the patch works. (however I thought patch-package would allow me to edit the files in the src folder, in readable JS...)
WORKING SOLUTION :
If you edit the files directly in the dist/ folder of the package instead of the src/ folder, the patch works fine.
Adding below npm script in package.json after patching worked for me.
scripts: {
"prepare": "patch-package",
}
The lines from yarn documentation explains about prepare
For compatibility reasons, scripts called install, postinstall, prepublish, and prepare will all be called after your package has finished installing.
After adding this script in package.json, the changes of module file in patches folder has been patched into respective node module.
I was trying to do the exact same thing with some package, let's call it "some_package". When I saw the EDIT 2 my mind just connected the dots...
To test changes locally
Modify the files in node_modules/some_package/src folder and then, go to the node_modules/some_package and run:
$ npm install
$ npm run <name of the script that generates the dist folder>
No need to run npx patch-package nor postinstall step.
I think that this approach doesn't work for all packages, it depends on how the modified package's package.json is configured. Specifically, pay attention where the browser field is pointing (in my case ./dist/some_package.js).
CAVEAT: You will have to run npm install and npm run every time you make an update to the package.
To test changes and be able to share it among team members (when the package is on Github)
Make a fork of the package you want to modify.
Make all the changes you want to your forked version of the package.
Run the following to automatically update the package.json file to make the dependency point to your forked version:
$ npm install <github's user name>/<package's name of the forked repository>#<branch name> --save-prod
For instance, if your Github's user name is "johndoe", and you forked https://github.com/aurelia/framework, and you made a branch named "mycoolbranch" containing your changes, then it would be:
$ npm install johndoe/aurelia-framework#mycoolbranch --save-prod
Note that the --save-prod flag could be replaced with --save-dev if the dependency is just for development.
Take a look at this answer, it may help.
https://stackoverflow.com/a/71153240/9981565
For me it was happening because of version mismatch between package.json intended version of package and yarn.lock / package-lock.json

Package.json pasting a package name in bad?

What happens differently when you go into your package.json and paste a package name in and do npm i vs. doing it the real npm i package-name?
package.json:
"dep": 1.0.0
vs
npm i dep --save
We have a build error and learned can bypass it by pasting. I know it isn't kosher but I really want to know why and what consequences that causes?
npm install dep doesn't add the dependency to the package.json file.
You have to add --save or --save-dev to add it to the package.json file.
Besides that, npm install will always serve you the latest build (in most cases the version tagged as latest (see npm docs)), unless you specify a specific version.
If you want your lock file to update, you have to delete the file before running npm install to generate a lock file with the dependency included (for more info check out this GitHub issue)
In conclussion it shouldn't make much of a difference if you manually add the dependency to package.json file and install it with npm install, unless the latest version of your dependency is broken.

Uninstalling global npm package leaves an error in npm list

I'm having some issues uninstalling some of my global npm packages, in that they don't appear to be fully removing.
As an example, I've been trying to remove the beta Angular CLI package (as this package was renamed for its 1.0.0 release). Running npm uninstall -g angular-cli appears to work, however when I then run npm list -g --depth=0 the package appears to remain in the list, now with an error:
error: ENOENT: no such file or directory, open '/usr/local/lib/node_modules/angular-cli/package.json
It appears as though the package has not been fully removed - I'm not sure if this can be fixed using npm prune, or simply by going in and manually deleting any files that may be left over.
I've not had any success googling around the issue, however this could be because I'm not entirely sure what to search for, as evidenced by my not-so-eloquently worded title for this question.
If anyone has any thoughts, I'd be very grateful to hear them!

Does npm delete downloaded module if the installation fails?

When I try to install something with npm it fails quite often (much more often that apt-get for example), and it will display "see log file for details" or "make in the directory failed". But when I try to inspect the directory said it will not be found. Does NPM simply delete every thing it just downloaded if anything fails during installation? Why would it tell me to check the directory then if it deleted it?
npm keeps downloaded packages as tarballs inside a cache folder.
see: https://www.npmjs.org/doc/cli/npm-cache.html
When you run npm install and something goes wrong, it will try to undo and remove the packages from your current location, but it should leave the cached tarballs alone. Sometimes the cache can have a bad package-tarball.
You can force npm to install without using the cache like this npm install --force. Or, if you really must, you can clear out the whole cache like this npm cache clean.
Remember: npm installs packages into the current folder, or wherever your package.json can be found

How to shrinkwrap npm modules without local dependencies

I tried to maintain package.json with the list of node modules dependencies. when I call npm install it installs the node modules.and generates a folder for it in my app. I call the npm shrinkwrap. But this generates the dependency on the local node module
"dependencies": {
"async": {
"version": "0.2.5",
"from": "async#0.2.5",
"resolved": "https://registry.npmjs.org/async/-/async-0.2.5.tgz"
},
when I upload the app to the appfog server it can install from the npm-shrinkwrap.json. So Ideally I want to remove the node modules folder and just pass the shrinkwrap.json file. But it has this "from". I had in the past generated the shrinkwrap & it didn't have the "from" field in there.
How to generate without "from"/ can I just get a shrinkwrap file from package.json. so my app will be leaner. I can maintain all the node module globally.
Thanks
I'm a bit confused by your question.
Shrinkwrap does not install, package, upload or do anything to your dependencies.
All it does is scan your installed node_modules and record the versions (recursively) into a file. Invoking npm install after that file is defined becomes repeatable, which is a principle of software engineering.
"from" was introduced a few months back. The npm shrinkwrap command seems to set it to the URL from which a module was installed. This is probably for portability. npm install takes a module name, consults a registry (whose URL is configurable as an npm config setting) and installs it. I could take the same package.json and npm-shrinkwrap.json, put them on another machine and theoretically get a different result if that machine's npm config settings point it to a different registry. Therefore, embedding the resolved URL in the shrinkwrap file adds an additional level of repeatability to npm install
See the npm config man page for details of setting the registry parameters.
According to npm issue 3145 on github, the "from" setting is known to cause backwards-compatibility issues with pre-1.2.x npm systems. Upgrading is the only resolution.
https://github.com/isaacs/npm/issues/3145
I think that you are looking for shrinkpack: https://www.npmjs.com/package/shrinkpack
from the doc:
Shrinkpack complements the npm shrinkwrap command by maintaining a node_shrinkwrap directory in your project, containing the exact same tarballs that npm install downloads from https://registry.npmjs.org.
The rest of the npm install process is exactly the same. The only difference is that no network activity is necessary when installing and building your project. The node_shrinkwrap directory can be ignored in your editor (much like is done with the node_modules directory) but is instead checked into source control.