npm workspace support

[marvinhagemeister]

Noticed that we're not able to resolve local workspace module in a monorepo setup.

Steps to reproduce:

1. Clone https://github.com/marvinhagemeister/deno-workspaces
2. cd into cloned repository
3. Run deno run packages/a/index.js

Error:

error: npm package '@marvinh/test-b' does not exist
    at file:///deno-workspaces/packages/a/index.js:1:28

[MellKam]

I also encountered this problem. It would be very nice to be able to test local npm packages with deno

[alshdavid]

I am also encountering this, it's a pretty substantial blocked for adopting Deno in my case.

I did some digging and it looks like this whole chain receives the resolved symlink path which fails to detect that we are in node_modules because Deno is looking for "node_modules" in the path

In the case of a workspace, the symlink will resolve to a file path in the local workspace, not within node_modules. I was trying to find where the value is resolved to see if I could prevent it from resolving the symlinked path but no luck.

[dsherret]

It might work with "unstable": ["byonm"] (bring your own node_modules), which will be the default in Deno 2.0

[alshdavid]

Currently it doesn't seem to with byonm. I couldn't find where Deno decides to enable require/module but in the files above the ByonmCliNpmResolver seems to identify if a file is an npm package by looking for node_modules in the filepath.

In the case of workspaces, local packages are symlinked into node_modules but if you follow the link it will be a local file.

So

/node_modules
  /a    -> /packages/a (symlink)
  /b    -> /packages/b (symlink)
/packages
  /a
    index.js
    package.json
  /b
    index.js
    package.json

If a depends on b the raw path should be /node_modules/b/package.json, however if you follow/resolve the symlink it will be /packages/b/package.json

The Byonm resolver looks at the latter path, which does not have node_modules in it, resulting in it returning false on NpmResolver.in_npm_package.

I don't know if Deno uses the result of this to decide if the import should have Node.js support

I also couldn't find where the path was being generated, I assume that simply avoiding following the symlink when generating the filepath is enough to fix this.

[alshdavid]

This might resolve the issues a lot of people are complaining about in this discussion - which centers around not being able to use Supabase + Deno within a symlinked workspace

https://github.com/orgs/supabase/discussions/7742

[pixeleet]

This is also a major blocker for implementing anything in a node monorepo that is purely targeted at deno e.g. @effect/platform-deno Effect-TS/effect#1806