Dependency with fetch-URL is completely ignored

I have a repoA with a package.json specifying some dependencies.

One of the dependencies is a fork of a famous library. Since the patches are for personal use I didn’t want to publish my fork to npm (also to avoid collisions in naming).
So I just changed the name in the package.json of my fork to have a name @myorg/famous-library-name”.

Then I have repoB that depends on repoA.
Not being registered I then just specify a name and URL to fetch from

{
  "dependencies": {
    "famous-library-name": "git+https://github.com/original-author/famous-library-name.git",
    "jquery": "^3.3.1",
    ...
  }
}

In the end I have a projectA repository that depends on repoB in its package.json.


Note: when doing npm install on the repoB I get the repoA correctly installed under node_modules/@myorg/famous-library-name.

The problem is that when I run npm install on projectA I get everything installed, under node_modules, except for the famous-library-name folder.

No error is given, the installation is successful but just that dependency is missing and all the other dependencies (e.g. jquery) are installed correctly under node_modules.


  • What is happening here?
  • How am I supposed to carry manually specified dependencies (that are not in the registry but should just be fetched via URL by Github.com) into my project?
  • Why the manual dependency is completely skipped by NPM without even reporting an error?

The behaviour is weird, since the dependency (repoA) of my projectA dependency (repoB) is not installed.
I thought the purpose of NPM was to install and flatten the dependency tree.
Why is it ignored?

Additionally and even weirder:

Using npm install --global-style I get the repoA dependency installed!
But it is being installed under node_modules/repoB/node_modules/@myorg/famous-library-name/.

But (because of the projectA structure) I need the dependency to be flattened and be placed under the main node_modules directory, rather than node_modules/repoB/node_modules/.

Can anybody give hints about this mysterious mess?

Before I offer any suggestions, I want to make more sense of your setup.

  1. Do you have three repos, A and B and F(amous), or is repo A the patched famous repo?

  2. Are both these statements as you intended, or is one backwards?

Then I have repoB that depends on repoA.

In the end I have a projectA repository that depends on repoB in its package.json .

  1. You mention both repoA and projectA, are these interchangeable or do you mean different things when you use those terms?
  1. FamousLibrary is a public repo that I do not own.
  • RepoA is my fork of FamousLibrary, where I add all my custom patches.
  • RepoB is a repo/library that I own; it has has RepoA as dependency.
  • ProjectA is a repo/project that depends on RepoB library, hence depending indirectly on RepoA.
  1. Both statements are as intended :slight_smile:
  2. Nope, RepoA and ProjectA are two different things. But you can call the project-A RepoC, if it helps your reasoning.

To recap:

ProjectA depends on ➜ RepoB, that depends on ➜ RepoA, that is a fork of ➜ FamousLibrary

The issue is when trying to get the installation of flattened dependencies on the ProjectA.

I tried reproducing, and things seemed to work fine.

ProjectA depends on ➜ RepoB , that depends on ➜ RepoA , that is a fork of ➜ FamousLibrary

I created RepoA (shadowspawn/8183-famous). In package.json I have:

  "name": "@shadowspawn/famous",

I created RepoB (shadowspawn/8183-repob) and installed RepoA as a dependency. That added a dependency:

    "@shadowspawn/famous": "github:shadowspawn/8183-famous"

I created ProjectA and installed RepoB as a dependency. That added a dependency:

    "8183-repob": "github:shadowspawn/8183-repob"

In ProjectA if I delete the node_modules folder and reinstall:

$ ls node_modules/*
node_modules/8183-repob:
package.json

node_modules/@shadowspawn:
famous

Thank you for you attempts! And good to see that the issue is on my side.

What NPM version do you have?
In my case the ProjectA is stuck to an old NPM3 version (3.10.10) with Node6 (6.14.4).
I have constraints preventing the upgrade, but before running npm install I usually run npm install --prefix vendor npm@5.6.0 so to get a more recent version (with hopefully enough bugfixes).

1 Like

I did the tests with npm v6.9.0.

I can’t upgrade node atm so I am stuck with older versions of NPM.

Funny fact is that the issue happens just with NPM 5.6.0.
If I don’t update it and stay with the NPM 3.10.10 installed on the machine, then everything works as expected and the fork of famous-dependency is correctly installed and then flattened by dedupe in the main node_modules/ :flushed::face_with_raised_eyebrow:

(Not perfect, since I get problems with extraneous modules and unmet deps, but that’s unrelated; the main installation works and the modules are where expected)

I am wondering why NPM3 works better than NPM5 :thinking:

There is an issue on the old repository mentioning this behaviour:


But in my case the version 5.3.0 doesn’t resolve the problem. :thinking:

I’ve made test with many NPM versions.

npm 4 & 6 are fine

Behaviour is as expected with version 6 (tested 6.9.0) and version 4 (4.6.1).

npm 5 is broken (edit: < 5.7.0)

While with all 5.x.x versions (tried 5.0.0, 5.1.0, 5.4.2 and 5.6.0) the installed tree is incorrect after doing npm install --prefix vendor --global-style && npm dedupe --prefix vendor.

I am struggling with this since weeks without being able to figure out what I did wrong… :weary: It took so much of my time:face_with_symbols_over_mouth:

Hoping at least this trace will help somebody in the future… :roll_eyes:


edit:

This was fixed from NPM 5.7.x; see the following post.

1 Like

Update:

NPM 5 is broken just until the 5.6.0.

I was thinking that one was the last compatible version with Node 4, and skipped the higher versons.

When trying the 5.7.1 I instead managed to get the same correct behaviour found with version 4 and version 6 !

Here is the explanation of what happens, when installing git-url dependencies (that are not published, from what I understood) on NPM:

Resolved indeed in NPM 5.7.1, but NONE of the previous 5.x version will be able to install correctly.