Resolving npm modules from node_modules higher in parent folders

[houshuang]

The new Yarn workspaces feature to make it easier to work with monorepos relies on hoisting common npm packages to the parent directory. Apparently this is part of the npm specification, that it will resolve by looking into the current node_modules, but also in node_modules in the parent folder. This works with node, and Webpack. However, Meteor's bundler only looks for modules in the current node_modules folder, and when it cannot find it, it errors out. (Version METEOR@1.6-beta.16).

We have our Meteor app organized as a mono-repo with several plugin packages that are required by the Meteor app. We used to use symlinking (which works well), but are looking at transitioning to the yarn workspace model (much faster install, less hand-written scripts).

[benjamn]

This will work if you start in a subdirectory of your Meteor app. That is, you can have multiple levels of node_modules directories, but they all have to be contained by the app. The location of your .meteor directory designates the root of your application, by the way.

Meteor does not, and will not ever, consider node_modules directories outside your application root directory, because that would require you to somehow recreate that surrounding environment on the server where you deploy your app. The app should be self-contained.

[hwillson]

As outlined in https://github.com/meteor/meteor/issues/9000#issuecomment-321578701, this isn't a Meteor issue. Thanks!

[apendua]

@benjamn

Meteor does not, and will not ever, consider node_modules directories outside your application root directory, because that would require you to somehow recreate that surrounding environment on the server where you deploy your app. The app should be self-contained.

We are in 2022 and this statement does not necessarily hold anymore in the world of docker containers. What needs to be self contained is the container itself. There's a lot of monorepo tooling nowadays, which rely on the fact that the application will be distributed as a docker container along with some surrounding directory structure. This is how rush works for example:

https://rushjs.io/pages/maintainer/deploying/#multiple-deployments-using-different-config-files

Meteor not being able to support this use case basically makes it impossible use Meteor for building multi-services applications maintained as a monorepo. It may not be critical for projects which are in an initial phase, but for larger ones this is kind of a deal breaker IMHO.