rogeriochaves / npm-force-resolutions

Force npm to install a specific transitive dependency version
567 stars 28 forks source link

.npmrc private registries ignored since 0.0.3 #26

Closed nalham closed 3 years ago

nalham commented 3 years ago

.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"
          }
        },
nalham commented 3 years ago

@rogeriochaves

I believe this is causing the behavior I'm seeing. https://github.com/rogeriochaves/npm-force-resolutions/blob/bb5366b80ed2ef45097b8ef7a2f837996a431f91/src/npm_force_resolutions/core.cljs#L25

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

Behavior: image

rogeriochaves commented 3 years ago

Thanks for reporting! This should be fixed now by 715bfeec0baefa0d3afc589230cc5f50d4904bae 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?

nalham commented 3 years ago

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"
             }
           }
         },
bpb54321 commented 3 years ago

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

nalham commented 3 years ago

@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"
}
rogeriochaves commented 3 years ago

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

nalham commented 3 years ago

@rogeriochaves 0.0.7 is working as expected, thanks!