Using Peer Dependencies With Local (file:../some-lib) Dependencies
Asked Answered
B

2

12

I have a monorepo that has many micro-services in it. There are some library-type functions / classes that I want to make available to any micro-service that needs it. However, if that library package declares a peer dependency, the peer dependency is not found when running code from within the thing that depends on the library.

Consider this repo structure:

  • lib
    • some-library (peerDepends on foo)
      • index.js (requires foo)
      • node_modules will be empty
  • services
    • some-service (depends on foo, and some-library)
      • index.js (requires some-library)
      • node_modules will have:
      • foo
      • some-library will be a symlink to ../../lib/some-library

When running node services/some-service/index.js, you'll get the error "Cannot find module 'foo'", emanating from lib/some-library/index.js.

Presumably this happens because node is only looking at lib/some-library/node_modules and any node_modules folder that is in an ancestor directory. But since this code was run from services/some-service (as the working directory), and because of the symlink in services/some-service/node_modules, I would've expected this to work.

Here's a repo you can easily clone to see the problem: https://github.com/jthomerson/example-local-dependency-problem

git clone [email protected]:jthomerson/example-local-dependency-problem.git    
cd example-local-dependency-problem    
cd services/some-service    
npm install    
node index.js    

I only see two solutions:

  • Don't use peerDependencies inside the library
  • Install each peer dependency at the root of the project for the sake of local development and testing.

Neither of those is a real great solution because it doesn't allow each service to have different versions of the dependencies, and thus means that if the local version (or the library's version) of a dependency is bumped, all services that uses the library then have their dependencies version bumped at the same time, which makes them more brittle because they're all tied together.

Brazzaville answered 11/6, 2018 at 23:23 Comment(0)
P
5

How about adding the --preserve-symlinks flag? E.g.:

node --preserve-symlinks index.js 

Here's a link to the docs

Postpone answered 12/6, 2018 at 1:58 Comment(0)
I
0

I had a dual-workspace setup in which:

workspace1

  • shared-library
  • module-library (peer depends on shared-library)

workspace2

  • main-app (depends on module-library and shared-library)

Now dependencies for workspace projects are defined in the tsconfig.base.json file under compilerOptions.paths.

However for workspace2 which is unrelated to workspace1, I install the packages (both via file:. When I then build main-app I get the error that module-library is unable to find shared-library (even though it's installed in workspace2.

I had to add ./../workspace1/dist/shared-library to the compilerOptions.paths in tsconfig.base.json of workspace2 (note the reference to workspace1).

This obviously couples the workspaces on my filesystem. But for development purposes this is perfect.

Infallibilism answered 4/10, 2020 at 22:12 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.