[rush] Dependency of dependency not installed

[RDeluxe]

Please prefix the issue title with the project name i.e. [rush], [api-extractor] etc.

Is this a feature or a bug?

• Feature
• Bug

Please describe the actual behavior.

I'm working on a project using NextJs.
I'm using a plugin, @zeit/next-css which has several dependencies in its package.json.

However, none of those are listed in the project node_modules after install (they are indeed present in "common") and thus the project won't compile.

This seems to be the case for a lot of dependencies actually, even though it seems they are correctly setup in package.jon files.

If the issue is a bug, how can we reproduce it? Please provide detailed steps and include a GitHub branch if applicable. Your issue will get resolved faster if you can make it easy to investigate.

Here is a simple repro (based on next-css example)

• clone the repo

• rush update

• npm run build

What is the expected behavior?

The project should compile correctly

If this is a bug, please provide the tool version, Node.js version, and OS.

• Tool: pnpm
• Tool Version: 2.15.1 (listed in rush.json)
• Node Version: v12.1.0
  • Is this a LTS version? No
  • Have you tested on a LTS version? No
• OS: Windows 10

[sachinjoseph]

Can you also include the steps to repro the issue?

[RDeluxe]

Sorry, true I forgot. It's a 2 step process, I added the command to my post. (also fixed a typo, I'm using pnpm and not npm)

[RDeluxe]

After digging more, it seems next as whole is really not pnpm friendly.

The SSR part expects a flatten node_module folder apparently, I have no idea how to mitigate this.

[octogonz]

Typically these incompatibilities center around two problems:

1. A package imports a dependency without declaring it in package.json. We call this a phantom dependency. This is usually easy for the package maintainers to fix. It's often as simple as adding a line to their package.json. To test a proposed fix, with PNPM you can use the common/config/rush/pnpmfile.js hook to patch the incorrect package.json during installation. This is a pretty decent workaround.

2. A package implements homebrew module resolution that does not conform to the standard. In simple cases, maybe the offending package tries to read ../some-dep/package.json or ../../package.json naively assumping that it got installed in a very specific place in the node_modules tree. In more complex cases (e.g. plugin loaders), they may implement a full node_modules probing algorithm, but without following symlinks correctly. This is a bit harder to fix. They may need to add calls to fs.realpathSync() in the right places, or just replace their custom algorithm with the resolve library.

The first step is getting the maintainer to recognize that their package is doing something incorrect. Even though PNPM and Yarn Plug'n'Play have been around for a long time now, there's unfortunately still a substantial monoculture who are unfamiliar with other installation strategies besides classic NPM.

[RDeluxe]

Thank you for your answer.

I'm aware that this may be caused by the way Next handle their dependency, even if in this case this is probably more problem number 2. I have no idea how to debug something like this however.

Actually with Next you can have problem at build time (ie: the example provided here) and then at runtime.

I'm not quite sure I can make them do anything about it to be honest, and PNPM's move toward "hoisting" is a sign that the battle is probably lost, sadly.

It would be great to see Rush supporting the new pnpm version v4.0.0-1, I've tried to use both together but it does not work for now (I'm digging in Rush code to see if I can find a fix)

[RDeluxe]

Thanks for your attention, to be honest this should probably be closed for now as it's more a PNPM "issue".

A PR was opened for this : vercel/next-plugins#415

But they closed it for now because they are thinking about a future architecture for CSS handling in Next.js.

However PNPM 4 support would be great.

[sadsa]

@RDeluxe - I've been chasing the same issue for days now. In my case, I'm using Parcel as a bundling tool and it seems to be the way modules are being resolved within the parcel-bundler itself. This could potentially be the same issue with NextJS.

See:

• existing issue on Github
• a PR submitted to fix this

[RDeluxe]

Hey!

I solved my problem by cloning and using my own versions of Next-plugins (applying the aforementionned fixes).

Took me some time though. Good to know that Parcel if unusable with PNPM for now

[apostolisms]

Closing since this seems to be resolved now. thanks