deno monorepo support does not support using dependencies in workspace packages

[alita-moore]

I am getting the following error

Relative import path "axios" not prefixed with / or ./ or ../ and not in import map from "file:///Users/alitamoore/workspaces/monorepo/libs/core/dist/src/errors/core.d.ts"

when running an edge function locally. The dependency is imported in a workspace package into the function. That worksapce package has dependencies. The workspace package is defined using package.json. This workflow is supported by deno, however, supabase does not interpret the package.json of the workspace package.

Yet the package.json has the necessary dependencies defined, but the system seems to require that it be a deno.json. To work around it I need to manually insert the dependencies in the deno.json even though I'm just duplicating the dependencies between package.json and deno.json.

[rdforte]

I am also experiencing the same issue. I am running a monorepo using Deno workspaces and I have a set of schemas in the schema directory that I would like to share across the frontend and my supabase edge function supabase/functions/api. The Deno linter seems to pick up the workspace just fine. It's only when I run supabase start && supabase functions serve api and hit the function on my local that I encounter this error.

Here is my current folder structure. I have omitted some of the folders and files for brevity

.
├── deno.json
├── deno.lock
├── frontend
├── schema
├── supabase
   ├── config.toml
   ├── functions
      └── api
          ├── deno.json
          ├── index.ts

any help on this would be much appreciated. I'm also happy to assist anyway I can.

[github-actions]

Hi! Thanks for opening this issue.

We're closing this because it has not had any activity for 45 days, and we try to keep the Supabase CLI issue tracker focused on reports that are still current.

If this still reproduces on the latest Supabase CLI, please comment with /reopen on its own line and include your CLI version, updated reproduction steps, and any recent error output. We appreciate the signal and are happy to take another look.

[alita-moore]

can this be re-opened please

[alita-moore]

❤️

[7ttp]

had a look and is reproducible...

curious if this is expected to be supported here for serve/deploy?
thoughts? @avallete @jgoux

[avallete]

The single-package case from #4549 (a function dir with its own package.json and no import map) is supported now. This issue is the harder, distinct one a function with a deno.json importing a local workspace package whose deps live in that package's own package.json and it's not supported yet.

The reason is a deliberate constraint in how we bundle today, not an oversight:

• deno.json and package.json are treated as mutually exclusive resolution modes. If an import map / deno.json is present, we set DENO_NO_PACKAGE_JSON=1 (and noNpm on serve), so package.json is ignored, including a workspace member's. This mutual exclusion exists on purpose because the "both present" combination caused npm-resolution bugs.
• We only look for a package.json sitting next to the entrypoint, never a workspace member's package.json elsewhere in the tree.
• The deploy bundler walks file imports only and skips bare specifiers, so a member's import "axios" is never collected.
• The Docker bundler mounts supabase/functions, not the whole monorepo, so member dirs outside that path aren't visible to the runtime.

Supporting this would mean relaxing all of the above at once, which is why the fully-general version (Deno workspaces) was previously scoped out.

For now the workaround is to declare the transitive deps in the function's deno.json. As the recommendation is to now share dependencies between functions so each function can be self-contained and bundled cleanly with (almost) only it's own folder.

I think this will eventually need a rewrite anyways so this can be fully supported. But I would not disregard the possibles breaking changes it might introduce.