BUG: on npm 2 builder postinstall fails if builder package includes another builder package

[boygirl]

On repos like axis that are on builder infrastructure, npm install will fail on builder postinstall if these packages include other builder packages.

failing CI in this PR is an example:
FormidableLabs/victory-axis#40
victory-label is using builder

[exogen]

After much experimentation, my conclusion is that npm@2 does something similar to npm@3: if package A depends on B and C, and C also depends on B, then npm@2 doesn't put B in C's node_modules, because it knows that when C requires B, it'll go up the node_modules chain and find A's version of B. It does this then A and C's version of B is compatible.

In short: we need to find where builder-react-component is even when installing with npm 2.

/cc @ryan-roemer

[ryan-roemer]

I'll test this out in a similar setup to the npmv3 thing soon.

Forward-looking note -- Once Chase lands builder init we should be able to add most of these types of scenarios to CI on the actual archetype.

[ryan-roemer]

Confirmed. In clean directory on npm v2 get:

Error

$ npm install FormidableLabs/victory-axis#refactor-1of2

> victory-label@0.1.2 postinstall /Users/rye/Desktop/TEMP_2/node_modules/victory-axis/node_modules/victory-label
> builder run npm:postinstall

\
/Users/rye/scm/fmd/builder/lib/config.js:95
    throw new Error("Unable to find package.json for: " + name);
          ^
Error: Unable to find package.json for: builder-react-component
    at Config._loadArchetypeScripts (/Users/rye/scm/fmd/builder/lib/config.js:95:11)
    at null.<anonymous> (/Users/rye/scm/fmd/builder/lib/config.js:139:26)
    at /Users/rye/scm/fmd/builder/node_modules/lodash/index.js:2874:23
    at arrayMap (/Users/rye/scm/fmd/builder/node_modules/lodash/index.js:1406:25)
    at map (/Users/rye/scm/fmd/builder/node_modules/lodash/index.js:6710:14)
    at interceptor (/Users/rye/scm/fmd/builder/node_modules/lodash/index.js:12240:26)
    at thru (/Users/rye/scm/fmd/builder/node_modules/lodash/index.js:5927:26)
    at baseWrapperValue (/Users/rye/scm/fmd/builder/node_modules/lodash/index.js:2768:30)
    at LazyWrapper.lazyValue [as value] (/Users/rye/scm/fmd/builder/node_modules/lodash/index.js:1077:16)
    at baseWrapperValue (/Users/rye/scm/fmd/builder/node_modules/lodash/index.js:2761:25)

It is likely a builder path issue, so let's keep this issue going and close the archetype one.

Notes

• This fails on node_modules/victory-axis/node_modules/victory-label/package.json:postinstall
• However, there is no node_modules in node_modules/victory-axis/node_modules/victory-label/. Shouldn't that be present?

[exogen]

However, there is no node_modules in node_modules/victory-axis/node_modules/victory-label/. Shouldn't that be present?

1. Not necessarily – I've noticed that if all of victory-label's deps are already satisfied in the above node_modules, then npm will skip creating it for victory-label entirely.
2. But it could also be: I think (but am not positive) that when npm encounters an error installing a module, it'll just completely wipe its node_modules as a form of cleanup. (Could be that I was just seeing the behavior in (1) afterwards, though.)

[ryan-roemer]

Interesting, so...

{
  "cwd": "/Users/rye/Desktop/TEMP_2/node_modules/victory-axis/node_modules/victory-label",
  "dir": "/Users/rye/Desktop/TEMP_2/node_modules/victory-axis/node_modules/builder/lib"
}

on an install means that the victory-axis / PARENT's builder is running in the victory-axis / CHILD's postinstall. It would be expected that we should be using the builder installed in victory-axis / CHILD instead.

[exogen]

@ryan-roemer Is dir there coming from __dirname? It most likely just means that builder was deduped as well (axis and label having compatible versions), not that it's running the wrong thing.

[ryan-roemer]

@exogen -- Where is the dedupe documentation for npm v2? I was under the impression it kept the entire child dependency tree, but haven't ever looked into this...

[exogen]

@ryan-roemer I searched last night and couldn't find any 😩 ...but the example in my comment above with packages A+B+C was tested with some minimal package.json configs on two different versions of npm 2, and it deduped. It might just be considered "npm internals" and not documented.

[exogen]

Note I also searched the old npm 2 CHANGELOG for any mention of this behavior, and couldn't find anything there either. I'm led to believe it's just been this way, and most of the time the tree is intact just because deps have different versions.

[exogen]

@ryan-roemer Hmm, if you search for "dedupe" here, it looks like npm has always done a basic form of this, even as far back as 1.x. (npm help dedupe reveals that this is the feature responsible.)

[ryan-roemer]

I always thought that was a separate manual command (https://docs.npmjs.com/cli/dedupe). But it definitely looks like it's happening here!