How do I nest incompatible projects?

[david-morris]

Details

In another issue I've noted that nesting certain node.js projects can break them. This is because the parent folders are in the import path, and this can cause incompatible versions of packages to be loaded.

This is a problem in the case of Docusaurus. Docusaurus needs to be able to read the contents of your main project to generate documentation. It would mess up folder structures to require that submodule to be a sibling of the main package.

Using bind mounts is also not a good solution because I'm working inside a docker container.

Node.js version

Not applicable. (happens on both 16.x and 18.x)

Example code

No response

Operating system

Windows 11/ WSL2/Docker linux stack.

Linux 921bd0682d97 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 GNU/Linux

Scope

Installation, importing.

Module and version

Not applicable. (the conflicting module happens to be @mdx-js/react)

[ljharb]

I'm confused why the docusaurus repo would need to exist on your machine; most tools like that are an executable that can live inside node_modules.

Either way, this isn't a node issue, this is a docusaurus one, since other docs generators don't have any issue like this.

[david-morris]

@ljharb what docs generators are you referring to? We are considering switching away from Docusaurus.

However, the submoduled repo isn't the Docusaurus dev repo; it's just a shared configuration including package.json between different projects, only one of which uses node. That makes it a lot easier to deploy the different projects' documentation together; they are a frontend and a backend.

[ljharb]

@david-morris maybe there's something i'm missing. If you have Outer and Inner, and both projects need a node package, then they're both node projects and should both have a package.json, that has explicit dependency entries for all the things they use.

However, if you want (altho it's not advisable) you could omit the declaration in Inner's package.json, and then run the command with Inner as the cwd.

[david-morris]

@david-morris maybe there's something i'm missing. If you have Outer and Inner, and both projects need a node package, then they're both node projects and should both have a package.json, that has explicit dependency entries for all the things they use.

However, if you want (altho it's not advisable) you could omit the declaration in Inner's package.json, and then run the command with Inner as the cwd.

If I understand correctly...
the problem is that some package made the assumption that it would only find one version of this package. So it starts looking for the newest first. But some other dependency needs that package to be loading the last major version down. Which yarn installed! But since the other package found the newer version in the parent git module node_modules, it doesn't get that and it crashes.

I'm currently throwing a bunch of bind mounts at the problem.

[ljharb]

If both Inner and Outer explicitly add docusaurus in their package.json, nesting shouldn’t change anything.

[david-morris]

If both Inner and Outer explicitly add docusaurus in their package.json, nesting shouldn’t change anything.

The problem is that only Inner adds docusaurus. Outer adds a package with a conflicting mdx parser version, which gets hoisted.

[ljharb]

They’re two separate projects, so they should have independent node_modules. If the projects work separately they should work nested too.

[david-morris]

They’re two separate projects, so they should have independent node_modules. If the projects work separately they should work nested too.

I agree, that's why I created this issue. Unfortunately they don't work nested. Not a problem since I'm using Docker and sprinkled my project with bind mounts so that the parent directory node_modules doesn't exist, but if I was trying to do this on Windows or Mac OS I'd be out of luck.

My understanding is that Node supports Mac OS and Windows?

[ljharb]

if you can set up a repro repo I’d be happy to take a look, but the only way a command run inside Inner can “escape” to Outer is if the command is using a dep that’s present in Outer and not declared/present in Inner.

[github-actions]

It seems there has been no activity on this issue for a while, and it is being closed in 30 days. If you believe this issue should remain open, please leave a comment.
If you need further assistance or have questions, you can also search for similar issues on Stack Overflow.
Make sure to look at the README file for the most updated links.

[github-actions]

It seems there has been no activity on this issue for a while, and it is being closed. If you believe this issue should remain open, please leave a comment.
If you need further assistance or have questions, you can also search for similar issues on Stack Overflow.
Make sure to look at the README file for the most updated links.