rogeriochaves / npm-force-resolutions

.npmrc file should be respected when running npx npm-force-resolutions

This is the package-lock.json chunk that was generated

"lodash": {
          "dev": true,
          "integrity": "sha512-PlhdFcillOINfeV7Ni6oF1TAEayyZBoZ8bcshTHqOYJYlrqzRK5hagpagky5o4HfCzzd1TRkXPMFq6cKk9rGmA==",
          "version": "4.17.20",
          "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.20.tgz"
        },

I'm expecting the resolved to be an internal one

"resolve": {
          "version": "1.20.0",
          "resolved": "https://{internalurl}/resolve/-/resolve-1.20.0.tgz",
          "integrity": "sha1-YpoBP7P3B1XW8LeTXMHCxTeLGXU=",
          "dev": true,
          "requires": {
            "is-core-module": "^2.2.0",
            "path-parse": "^1.0.6"
          }
        },

@rogeriochaves

I believe this is causing the behavior I'm seeing.

npm-force-resolutions/src/npm_force_resolutions/core.cljs

Line 25 in bb5366b

    
           (let [response (<! (http/get (str "https://registry.npmjs.org/" key "/" version)))

This parameter should pull from .npmrc registry key's value and default to https://registry.npmjs.org/

Behavior:

Thanks for reporting! This should be fixed now by 715bfee and released on version 0.0.6, although I didn't have time to test on a private registry myself yet. Could you try and let me know?

0.0.6 the resolved url is correct, but integrity is null

package-lock.json generated snippet

           "dependencies": {
             "lodash": {
              "integrity": null,
              "version": "4.17.20",
              "resolved": "https://{privateUrl}/lodash/-/lodash-4.17.20.tgz"
             }
           }
         },

This is happening for my team as well, looking forward to the resolution of this issue!

@rogeriochaves

https://docs.npmjs.com/cli/v6/configuring-npm/package-lock-json#integrity

1. For bundled dependencies this is not included, regardless of source.
2. For registry sources, this is the integrity that the registry provided, or if one wasn't provided the SHA1 in shasum.
3. For git sources this is the specific commit hash we cloned from.
4. For remote tarball sources this is an integrity based on a SHA512 of the file.
5. For local tarball sources: This is an integrity field based on the SHA512 of the file.

I believe bullet 2 is the flow that would need to be added to support my use case

Here is what our registry shows for a package lodash@4.17.20. Our registry proxy does not provide a dist.integrity key like npmjs.org does, instead it only provides the dist.shasum

{
    "name": "lodash",
    "description": "Lodash modular utilities.",
    "version": "4.17.20",
    "author": "John-David Dalton <john.david.dalton@gmail.com>",
    "homepage": "https://lodash.com/",
    "repository": "lodash/lodash",
    "contributors": [
        "John-David Dalton <john.david.dalton@gmail.com>",
        "Mathias Bynens <mathias@qiwi.be>"
    ],
    "main": "lodash.js",
    "dist": {
        "tarball": "https://{privateUrl}/lodash/-/lodash-4.17.20.tgz",
        "shasum": "b44a9b6297bcb698f1c51a3545a2b3b368d59c52"
    },
    "keywords": "modules, stdlib, util",
    "license": "MIT",
    "scripts": {
        "test": "echo \"See https://travis-ci.org/lodash-archive/lodash-cli for testing details.\""
    },
    "icon": "https://lodash.com/icon.svg"
}

thanks for finding the docs @nalham, I looked for it but couldn't find this part myself. This should now be fixed by 986fb7c, and released on v0.0.7, please let me know if that works!

@rogeriochaves 0.0.7 is working as expected, thanks!

.npmrc private registries ignored since 0.0.3