I have a project in a personal private git, I downloaded in another computer and when trying to download the packages in packages.json i got this error message:
pablo#debian:~/Documents/clients/stock$ npm install
npm WARN package.json Stock#0.0.1 No repository field.
npm WARN package.json Stock#0.0.1 No README data
This is the content of the packages.json
{
"name": "Stock",
"version": "0.0.1",
"description": "Stock App",
"devDependencies": {
"grunt": "~0.4.5",
"grunt-contrib-watch": "^0.6.1",
"grunt-execute": "^0.2.2",
"socket.io": "latest",
"mysql": "latest",
"express": "latest",
"path": "latest",
"express-session": "latest",
"cookie-parser": "latest",
"ejs": "latest"
},
"dependencies": {
"socket.io": "~1.3.7",
"body-parser": "~1.14.1"
}
}
What can I do, to packages to download, and why in my other computer I don't get this error?
These warnings are just warnings, and don't indicate anything reason that the dependencies would not have downloaded.
The package.json file shown is working perfectly for me. To debug your issue, try removing the node_modules folder and running npm install again. Note that if the packages are already in the node_modules folder, npm install won't download them again.
If you want to fix the warnings:
Before devDependencies, add a repository option; i.e. something like:
"repository": {
"type": "git",
"url": "[git-url-of-your-project]"
},
The URL doesn't have to be a github one, just whatever you use to git
clone the project on another computer.
Add a file called README or README.md and write a few words about what the project is in it.
Mark your application as private to suppress all warnings by adding "private": true
{
"name": "Stock",
"version": "1.0.1",
"private": true
}
I found removing the node_modules folder and doing 'npm install' from fresh seemed to fix my issues.
Just add your package.json file from
C:\Program Files\nodejs\node_modules\npm
to
C:\Windows\System32
and everything will be fine and working. Hope it helps.
Related
I have a large, existing package-lock.json and a lot of dependencies that have been resolved via http://registry.npmjs.org/.
e.g.
{
"name": "my-package",
"version": "1.2.3",
"lockfileVersion": 1,
"requires": true,
"dependencies": {
"#babel/cli": {
"version": "7.7.4",
"resolved": "https://registry.npmjs.org/#babel/cli/-/cli-7.7.4.tgz",
"integrity": "sha512-O7mmzaWdm+VabWQmxuM8hqNrWGGihN83KfhPUzp2lAW4kzIMwBxujXkZbD4fMwKMYY9FXTbDvXsJqU+5XHXi4A==",
"dev": true,
"requires": {
"chokidar": "^2.1.8",
"commander": "^4.0.1",
"convert-source-map": "^1.1.0",
"fs-readdir-recursive": "^1.1.0",
"glob": "^7.0.0",
"lodash": "^4.17.13",
"make-dir": "^2.1.0",
"slash": "^2.0.0",
"source-map": "^0.5.0"
},
"dependencies": {
"commander": {
"version": "4.0.1",
"resolved": "https://registry.npmjs.org/commander/-/commander-4.0.1.tgz",
"integrity": "sha512-IPF4ouhCP+qdlcmCedhxX4xiGBPyigb8v5NeUp+0LyhwLgxMqyp3S0vl7TAPfS/hiP7FC3caI/PB9lTmP8r1NA==",
"dev": true
},
"make-dir": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/make-dir/-/make-dir-2.1.0.tgz",
"integrity": "sha512-LS9X+dc8KLxXCb8dni79fLIIUA5VyZoyjSMCwTluaXA0o27cCK0bhXkpgw+sTXVpPy/lSO57ilRixqk0vDmtRA==",
"dev": true,
"requires": {
"pify": "^4.0.1",
"semver": "^5.6.0"
}
},
"pify": {
"version": "4.0.1",
"resolved": "https://registry.npmjs.org/pify/-/pify-4.0.1.tgz",
"integrity": "sha512-uB80kBFb/tfd68bVleG9T5GGsGPjJrLAUpR5PZIrhBnIaRTQRjqdJSsIKkOP6OAIFbj7GOrcudc5pNjZ+geV2g==",
"dev": true
},
"source-map": {
"version": "0.5.7",
"resolved": "https://registry.npmjs.org/source-map/-/source-map-0.5.7.tgz",
"integrity": "sha1-igOdLRAh0i0eoUyA2OpGi6LvP8w=",
"dev": true
}
}
},
...
I have my registry configured to be an NPM Enterprise installation that hosts proprietary NPM packages and mirrors the public NPM registry.
registry = "https://custom.registry.tld/path/npm/npm-aggregate"
This works for newly installed packages, but many existing packages still point to the public NPM registry. I tried overwriting the package-lock.json using npm i or npm i --package-lock-only.
How can I force NPM to use my Enterprise NPM registry and write the correct resolved URLs to package-lock.json? I probably could just "find and replace", but I want to make sure that NPM is resolving dependencies correctly.
I am running npm -v 6.14.15
I simply changed the registry entries manually in the package-lock.json and deleted the node_modules folder, then ran an npm i to solve this issue.
Some solutions that didn't work for me:
When I tried to change the registry simply using the npm CLI by clearing the cache npm cache clear --force, and npm i --registry none of this worked. The registry didn't change at all, and in fact was reverted after running npm i in any form.
I then tried to remove the package-lock.json and node_modules and ran an install. This caused a lot of versions in my package-lock.json to change and caused my particular projects builds to fail.
I found that the steps I followed got what I wanted although it may not be a part of best practices with npm.
Overriding the registry will not replace existing "resolved": "https://xxx..." entries in the package-lock.json.
If this one is wrong from a previous creation, you have to delete it, then run again your npm i. It will create a fresh one with the registry previously configured.
Unfortunately, the package-lock.json file is meant to hardcode the registry of each package. It is intended.
We could imagine a future option in NPM to force the registry, in combination with an integrity check to make sure the packages are identical. (Feel free to send a feature request to the core team)
As of today, npm does not cover this use case. You are forced to ignore the package-lock.json to bypass this limitation.
(as of today, the latest version of NPM is 8.13.2)
Find/replace registry in package-lock
Delete node_modules
Verify npm install works
My package.json file looks like the following :
{
"name": "anna-backend",
"version": "1.0.3",
"description": "Backend for ANNA intranet",
"main": "app.js",
"author": "IpsaOne DevTeam",
"private": true,
"license": "ISC",
"dependencies": {
"async": "^2.6.0",
"bcrypt": "^1.0.3",
"body-parser": "^1.17.2",
"mmmagic": "^0.4.6",
[...]
}
}
When I run npm install in the folder, everything installs well except the dependencies that require building via node-gyp (like bcrypt, mmmagic) and I have to install them manually by typing npm install mmmagic. Otherwise, they're just not installed and my application doesn't start.
Is it expected behaviour ? Can I do anything about it ?
mmmagic module has issues on install
https://github.com/mscdex/mmmagic/issues/111
try install at last version 0.5.0
I have a repository containing a package.json which contains scoped dependencies. I also have an .npmignore file intended to whitelist all files and subdirectories in dist/. The problem is all of the scoped dependencies are included when running npm install #private/a another repository. This includes both private npm packages and public packages such as #uirouter.
package.json:
{
"name": "#private/a",
"version": "1.0.0",
"description": "",
"main": "dist/index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"repository": {
"type": "git",
"url": "git+ssh://git#bitbucket.org/private/a.git"
},
"author": "",
"license": "ISC",
"homepage": "https://bitbucket.org/private/a#readme",
"devDependencies": {
"gulp": "^3.9.1",
"gulp-angular-embed-templates": "^2.3.0",
"gulp-concat": "^2.6.1",
"gulp-jshint": "^2.0.4",
"gulp-rename": "^1.2.2",
"gulp-sass": "^3.0.0",
"gulp-uglify": "^2.0.0",
"jshint": "^2.9.4"
},
"dependencies": {
"#private/b": "^1.0.0",
"#private/c": "^1.0.0"
}
}
.npmignore
**
!dist/**
Despite these two files when I run npm install #private/a --save within another repository it is installing the dependency along with all it's scoped dependencies:
/node_modules/#private/a/dist/index.js
/node_modules/dist/css/styles.css
/node_modules/#private/a/node_modules/#private/b
/node_modules/#private/a/node_modules/#private/c
package.json
It should only be this:
/node_modules/#private/a/dist/index.js
/node_modules/dist/css/styles.css
package.json
How can I achieve this? I have tried different variations of the .npmignore but have not had any luck.
.npmignore is irrelevant to what you are trying to do. This file only decides which parts of your npm package code ends up in npm registry. So it is working as advertised.
Your problem must be in your npmconfig or because of using an older version of npm. The latest version installs stuff as so:
/node_modules/#private/a/dist/index.js
/node_modules/#private/b/...
/node_modules/#private/c/...
package.json
I have verified that this is happening with latest npm. But there used to be a time when npm installed dependencies into a nested structure. See this for example. So I suggest:
Making sure you have latest node and npm.
Making sure your npm config is not forcing legacy bundling. Run npm get legacy-bundling. Make sure this is false.
There are few cases where the nesting of dependencies happens legitimately even with the latest npm. See this. But I am guessing your problem is not due to this. You can test by simply doing npm install #private/a in an empty folder.
Node will install your package files along with all the dependencies declared under dependencies field.
How the dependencies tree is build, depends on which version of npm do you use.
If your package doesn't need those dependencies to run, it means they are just dev dependencies and you can safely list them under devDependencies field.
Dev dependencies are only installed when you run an npm install inside the plugin directory.
You need to lock your dependency. You might want to check out npm shrinkwrap.
I'm using npm v1.4.4 and node v0.10.25 on Mac OS X 10.9.2.
I've recently upgraded node and npm, and now npm install is no longer creating the .bin directory in node_modules.
I've deleted node_modules, tried npm install again, but the directory and binaries are never created.
Does anybody have any ideas as to why this is happening?
Here is my package.json:
{
"name": "redacted",
"author": {},
"description": "redacted",
"dependencies": {
},
"devDependencies": {
"karma": "*",
"karma-coverage": "0.1.2",
"karma-junit-reporter": "*",
"karma-coffee-preprocessor": "~0.1",
"grunt": "^0.4.2",
"grunt-contrib-requirejs": "^0.4.3",
"grunt-contrib-concat": "^0.3.0",
"grunt-contrib-sass": "^0.7.2",
"grunt-contrib-htmlmin": "^0.2.0",
"grunt-contrib-cssmin": "^0.7.0",
"grunt-contrib-coffee": "^0.10.1",
"grunt-contrib-uglify": "^0.3.3",
"grunt-contrib-jst": "^0.5.1",
"grunt-contrib-qunit": "^0.4.0",
"grunt-contrib-jshint": "^0.8.0",
"grunt-contrib-watch": "^0.5.3",
"grunt-contrib-jasmine": "^0.6.1",
"grunt-contrib-compress": "^0.6.1",
"grunt-contrib-handlebars": "^0.6.1",
"grunt-contrib-less": "^0.9.0",
"grunt-contrib": "^0.9.0"
}
}
I know this is an old post but I experienced the same issue recently. I had copied files from an existing project including package.json and package-lock.json. The package-lock.json was what prevented the node_module/.bin directory from being created.
The solution was to delete the node_modules directory and package-lock.json and run npm install again
The ./node_modules/.bin directory is where npm creates links to a node package's binary. From https://docs.npmjs.com/files/folders#executables
Executables
When in global mode, executables are linked into
{prefix}/bin on Unix, or directly into {prefix} on Windows.
When in local mode, executables are linked into ./node_modules/.bin so
that they can be made available to scripts run through npm. (For
example, so that a test runner will be in the path when you run npm
test.)
The package.json you pasted above do not have a bin section. Take a look at this example from npm's package.json
{
"version": "1.4.9",
"name": "npm",
"publishConfig": {
"proprietary-attribs": false
},
"description": "A package manager for node",
...
...
"main": "./lib/npm.js",
"bin": "./bin/npm-cli.js",
"dependencies": {
"abbrev": "~1.0.4",
"ansi": "~0.2.1",
...
...
Specifically the line "bin": "./bin/npm-cli.js" will tell npm to create a link at ./node_modules/.bin/npm to node_modules/npm/npm-cli.js
Seems that all your dependencies are dev dependencies.
Could you see if your NODE_ENV environment variable is set to production now? If yes you will need to change it back.
Also, any error happened during installation?
If all packages installed, only the .bin is gone.
you can just run npm rebuild
In my case I had webpack running in watch mode in another console window. I did not get any errors during npm install so it took me a moment to notice.
Ensure the dependencies are not in use, such as karma running tests or webpack running in watch mode
Delete the dependency folders, such as node_modules/karma, or the entire node_modules folder. NPM does not seem to create symlink files in .bin folder if dependency folder already exists.
Retry npm install
With NPM 6.7.0.
Not really an answer to your question, but because I had a similar situation: I run npm with the --no-bin-links option on my VM so my windows host doesn't complain. And then later I don't find the bin links folder... duh!
This could happen because of the broken npm. Try following command from the npm troubleshooting and it should just work fine.
curl -L https://www.npmjs.org/install.sh | sh
There is connect-assets in my package.json's dependencies. And its package.json looks like:
"dependencies": {
"connect-file-cache": "0.2.4",
"mime": "1.2.2",
"snockets": "1.3.6",
"underscore": "1.1.7"
},
"devDependencies": {
"async": "0.1.14",
"coffee-script": "~1.3.1",
"connect": "1.8.5",
"nib": "0.2.0",
"bootstrap-stylus": "0.2.0",
"nodeunit": "0.5.4",
"stylus": "0.22.2",
"request": "2.1.1",
"watchit": "0.0.4",
"less": "1.3.0"
}
But when I ran npm install(with or without --dev and --dev-all), it only installed connect-assets, no stylus, nib, etc.
How should I do?
It's simply because the npm should not work this way. If I want to install the devDependencies of some depended modules, I have to enter their directories.
One should be aware that npm will not deliver files that are specified in the .npmignore file. This might be the culprit if one was looking to use files in a devDependency that exist in the git repo, but mysteriously are not present in the npm delivery.