package-lock.json resolved link points to local artifactory URL instead of globally set registry - npm

I have a .npmrc file with:
registy=http://artifacts.sample.com/artifactory/api/npm/
package-lock.json contains resolved field for dependencies which looks something like:
"dependencies": {
"acorn": {
"version": "5.7.3",
"resolved": "http://artifacts.sample.com/artifactory/api/npm/acorn/-/acorn-5.7.3.tgz",
"integrity": "sha512-T/zvzYRfbVojPWahDsE5evJdHb3oJoQfFbsrKM7w5Zcs++Tr257tia3BmMP8XYVjp1S9RZXQMh7gao96BlqZOw==",
"dev": true
}
Now, when I do npm install, it changes the package-lock.json resolved field to point to a local artifactory instead of the one specified in .npmrc like:
"dependencies": {
"acorn": {
"version": "5.7.3",
"resolved": "http://localrepo.sample.com/artifactory/api/npm/acorn/-/acorn-5.7.3.tgz",
"integrity": "sha512-T/zvzYRfbVojPWahDsE5evJdHb3oJoQfFbsrKM7w5Zcs++Tr257tia3BmMP8XYVjp1S9RZXQMh7gao96BlqZOw==",
"dev": true
}
We have localized code and this will give access denied to someone living on the other side of the world, where their artifacts URL points somewhere else, or it will just change the package-lock.json file for them to point to their local URL instead, and we will always have changing package-lock.json file.
I had issues with "dev" and "integrity" too, but they were fixed using https://github.com/npm/npm/issues/16938#issuecomment-339863980
I'm on the latest versions of node and npm.
node -v
v10.15.3
npm -v
6.9.0
Is there anyway we can avoid this?

From my own experience. If you have setup default registry, the "resolved" field in package-lock.json will have no effect. I just followed Artifactory npm registry official doc.
npm config set registry https://artifactory.my.com/artifactory/api/npm/npm-repo/
npm login
npm config set //artifactory.my.com/artifactory/api/npm/npm-repo/:always-auth=true
Alternatively, a simple trick is to update the host file (eg. /etc/hosts) to ensure the "resolved" field url is never reachable, this will help you to observe npm behaviour.

Related

"resolved" and "integrity" go missing in package-lock.json

Ocassionally, when installing an (unrelated) dependency, I lose the resolved values from each of my private nexus repository dependencies, meaning that when my build server runs npm ci it falls back to attempting to install these from the npm repository, which obviously fails.
I am using npm 8.5.5/node 16.15
I am using NPM's workspaces feature to construct a monorepo, meaning that I have several project package.json files as well as a root package.json
My .npmrc (at root level) looks like this:
engine-strict=true
#foo:registry=http://prod-nexus.foo.com/repository/bar/
always-auth=true
After an (unrelated, random) install my package-lock.json will have this change:
"#foo": {
"version": "1.2.3",
- "resolved": "http://prod-nexus.foo.com/repository/bar/#foo/-/lib-1.2.3.tgz,
- "integrity": "sha...",
+ "license": "MIT",
"dependencies": { ....
Note that the resolved and integrity fields have disappeared and the license has been added.
I have run into this problem several times, each time I have solved it by rolling back and some manual editing and eventually it goes away, but I really need to understand what is going on.
What is causing this, why is it random, what can I do to defend against it?
This could be related to the issue https://github.com/npm/cli/issues/4263
clean the npm cache npm cache clean -f
run npm install again
If that doesn't work, try it again while deleting more:
clean the npm cache npm cache clean -f
remove node_modules in project folder
remove package-lock.json file
run npm install again

package-lock.json in npm workspaces

Given an npm workspace with the following structure
workspace
package.json
packages
package-a
package.json
package-b
package.json
When I run an install command in package-a this will generate a package-lock.json file in the root of the workspace but not in the package.json file itself.
Is there a way to also generate it in the packages?
I don't know if this solves your problem, but you can specifie the folder in which you would install with --prefix
npm install --prefix ./install/here
you can use the lerna tool to manage your workspace and install dependencies in each package. you can generate package-lock.json files in each package in your workspace.
The Original Tool for JavaScript Monorepos. Monorepo means a repository with multiple packages.
lerna.js.org
I hope this answer will show you the right direction.
In most cases, running npm install within that package directory should do the job. But as you said that this is creating a global package-lock.json. This might be because the package you are installing might be specifying the global path using the prefix field.
The "prefix" field, specifies the location where the package's dependencies should be installed.
So one thing you can do is to go to the package.json in package-a and then either remove the prefix field from the package.json file OR set its value as following :
{
"name": "my-package",
"version": "1.0.0",
"prefix": "./",
"dependencies": {
...
}
}
Now when you run npm install it should install the packages locally and make a local 'package-lock.json`.

Why does jsonlines package get resolved to registry.npm.taobao.org?

When I install the npm package jsonlines, it gets resolved to a mirrored registry registry.npm.taobao.org rather than registry.npmjs.org. It only does this for jsonlines. What causes this?
Here's the diff on my package-lock.json. The original "resolved" value was created when another developer installed the package:
"jsonlines": {
"version": "0.1.1",
- "resolved": "https://registry.npmjs.org/jsonlines/-/jsonlines-0.1.1.tgz",
+ "resolved": "https://registry.npm.taobao.org/jsonlines/download/jsonlines-0.1.1.tgz",
"integrity": "sha1-T80kbcXQ44aRkHxEqwAveC0dlMw="
},
I confirmed my configured registry is npmjs.org:
$ npm config get registry
https://registry.npmjs.org/
The developer's npm registry was likely set to registry.npm.taobao.org when they ran npm install jsonlines. Some users have npm configured to use the taobao registry for geographic proximity.
Deleting node_modules and package-lock.json and re-running npm install fixes it.
Tip: Use lockfile-lint to prevent it from happening again.
npm install --save-dev lockfile-lint
Run lockfile-lint to your lint script, ideally in a pre-push git hook.
Add this config to your package.json:
"lockfile-lint": {
"allowed-schemes": [
"https:"
],
"allowed-hosts": [
"npm"
],
"empty-hostname": false,
"type": "npm ",
"path": "package-lock.json"
},

npm5 package-lock.json different entries on different machines

Our project uses npm for package management. After upgrading from npm 4 to npm 5, we decided to opt-in for the new package-lock.json.
After committing it and performing npm install on other machines, we spotted differences in the way the version and resolved entries are specified:
1) example of package-lock.json dependencies with version encoded as URL:
"jspm": {
"version": "https://registry.npmjs.org/jspm/-/jspm-0.16.52.tgz",
"integrity": "sha1-axhH4I8TGsm9JnzFiXSXmudnXS4=",
"dev": true
},
"systemjs": {
"version": "https://registry.npmjs.org/systemjs/-/systemjs-0.19.46.tgz",
"integrity": "sha1-wEV0szNfBSoOPHoA7kGIxuTB444=",
"dev": true
},
2) example of package-lock.json dependencies with version and resolved properties:
"jspm": {
"version": "0.16.53",
"resolved": "https://registry.npmjs.org/jspm/-/jspm-0.16.53.tgz",
"integrity": "sha1-VvNR9JWUyJM+XgG2UUWsrr/PtZ4=",
"dev": true,
"dependencies": {
...
}
},
"systemjs": {
"version": "0.19.46",
"resolved": "https://registry.npmjs.org/systemjs/-/systemjs-0.19.46.tgz",
"integrity": "sha1-wEV0szNfBSoOPHoA7kGIxuTB444=",
"dev": true
},
...
In addition to having an unstable package-lock.json, our build server is having issues when installing the first example.
Follow this procedure to produce a stable version of the package-lock.json:
delete the existing node_modules folder
delete the existing package-lock.json
perform npm install
commit and push the package-lock.json
For the rest of the team:
delete the existing node_modules folder
pull the new package-lock.json
perform npm install
Deleting the existing node_modules before continuing is an essential step because the package-lock.json does parse existing metadata from the node_modules folder.
This means that if your node_modules folder has leftovers, they may get added to the package-lock's dependencies, even if they're not an actual dependency (anymore).
You may want to check in this situation on both machines that:
your node + npm version are the same and maybe doing npm -g update npm.
the npm configuration property save-exact has the same value on both machines. (otherwise doing npm config set save_exact true/false)

Custom paths for package managers like Nuget/npm/bower/typings

I'm setting up a project in Visual Studio based on AngularJS and Typescript and it's a bit discouraging that I have to deal with yet another package manager as soon as I need to install dependencies.
The issue I have is that package managers require files containing dependencies to be located in a particular place.
Let's take npm for example.
I place packages.json at ./SolutionDirectory/MyApp.Web/
But when I run npm install, I just get ENOENT: No such file or directory. because cwd is ./SolutionDirectory
It works fine if I'm doing cd ./SolutionDirectory/MyApp.Web and run npm install after that.
For bower I was able to handle similar issue by just passing additional arguments like:
bower install --config.cwd=./SolutionDirectory/MyApp.Web/app/lib --config.directory=vendor
This command just gets bower.json from ./SolutionDirectory/MyApp.Web/app/lib and installs packages to ./SolutionDirectory/MyApp.Web/app/lib/vendor
Is there a way to have same thing to pass packages.json location to npm before it installs?
Is there a way to pass typings.json location to typings before it installs? to pass target directory location for typings installed?
Is the same doable for Nuget?
For npm:
npm install <folder>
<folder> is the path to the folder which contains the package.json file.
For typings:
typings install [<name>=]<location>
<location> is the path to the typings.json
For NuGet:
nuget install packageId|pathToPackagesConfig [options]
pathToPackagesConfig is the path to the packages.config file.
So, to answer the question, yes it's possible to specify a path to the config file's location for all of these package managers.
Is there a way to have same thing to pass packages.json location to npm before it installs?
No, there isn't. Currently there is no way to overwrite cwd value in npm. You should move directory and run it:
`$ cd SolutionDirectory/MyApp.Web/ && npm install`
Here is the similar discussion to this: https://github.com/npm/npm/pull/10958
Is there a way to pass typings.json location to typings before it installs? to pass target directory location for typings installed?
Technically yes, but I guess you'd like to just do typings install with typings.json. How about to put typings.json to the same path with package.json and use npm lifecycle script?
$ ls
package.json typings.json
$ cat package.json
{
"name": "name",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"postinstall": "typings install"
},
"keywords": [],
"author": "",
"license": "ISC",
"devDependencies": {
"typings": "^0.7.12"
}
}
$ npm install
=> after npm install, typings install will start with typings.json
Is the same doable for Nuget?
Nuget is also package manager, so it should has similar features, like nuget mirror command can be npm config set registry and nuget locales can be npm cache I guess. Technically it's a different software, but I think understanding about both softwares is good way to know the concept and summary of each others.