i_use_arch_btw•2w 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 doesn't work - Consequently, Deno isn't aware of package's exports and, more importantly, 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?

2 Replies

marvinh.•2w ago

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•2w ago

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:

{
  "workspace": {
    "members": ["../workspace-a/packages/core"]
  }
}

{
  "workspace": {
    "members": ["../workspace-a/packages/core"]
  }
}

error: Workspace member must be nested in a directory under the workspace.
  Member: file:///home/quacumque/Projects/workspace-a/packages/core/
  Workspace: file:///home/quacumque/Projects/workspace-b/

error: Workspace member must be nested in a directory under the workspace.
  Member: file:///home/quacumque/Projects/workspace-a/packages/core/
  Workspace: file:///home/quacumque/Projects/workspace-b/

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 =(

Workspace-aware path imports

Did you find this page helpful?