Deno•9mo ago

Workspace-aware path imports

Hi!

My use case: I want to import a package from a Deno workspace. It doesn't work:

Simply specifying path to the package root or its
```
deno.jsonc
```
```
deno.jsonc
```
doesn't work
Consequently, Deno isn't aware of package's
```
exports
```
```
exports
```
and, more importantly,
```
imports
```
```
imports
```

I am using the same mental model that works with Cargo: just specify the path, and Cargo will resolve everything.

[dependencies]
some_package = { path = "../../workspace_a/packages/some_package" }

[dependencies]
some_package = { path = "../../workspace_a/packages/some_package" }

Cargo understands that this is a crate, and it is a part of a workspace, and Cargo will resolve this crate's dependencies and everything accordingly.

I would really like if it works in Deno the same way.

Or is there a way to achieve the same right now?

marvinh.•3/25/25, 7:25 AM

Follow the official guide in our documentation on how to use workspace in Deno https://docs.deno.com/runtime/fundamentals/workspaces/ . This will address your issue

Deno

Workspaces and monorepos

A guide to managing workspaces and monorepos in Deno. Learn about workspace configuration, package management, dependency resolution, and how to structure multi-package projects effectively.

i_use_arch_btwOP•3/25/25, 11:55 PM

This does not address my issue, unfortunately.
I technically have 2 different workspaces. And I want to import package(s) from workspace A in workspace B, treating workspace A as a "black box".
As an experiment, I tried to define package of workspace A as a "member" in workspace B, and I got an error:

i_use_arch_btwOP•3/25/25, 11:57 PM

This, tied with inability to produce NPM tarballs for a JSR package, makes it very difficult to test changes / prototype new features to the workspace A locally, as an "external" user of the packages =(