Support for Deno packages

[amitav13]

Which project is this feature idea for?

Turborepo

Describe the feature you'd like to request

We currently have supabase edge functions (written in TS) sitting in a package that we deploy independently of the rest of our Node/React packages and apps. We also have a common package that houses types and other utils that we use across our apps. We want to pull these in to our supabase functions as well.

Describe the solution you'd like

I'd ideally want to just import the common package like we do in the rest of our apps, a line in package.json -

"common": "workspace:*"

Describe alternatives you've considered

A workaround would be to publish our package on npm and then add it in as a regular esm.sh import from a URL - though we lose all the goodness from having it as an internal dependency.

[tknickman]

Hey @amitav13, thanks for the issue. This is something that isn't immediately on the roadmap. Deno is pretty different in that there is no package manager or lockfile - everything is url based. Even the common standard of storing and exporting dependencies from deps.ts and dev_deps.ts is just a convention, and not enforced. This would make integrating turborepo difficult as the dependency paradigm is quite different.

I'll leave this issue open so we can continue to gauge interest from the community, but as of now it's not something we're planning on in the short term.

[oneezy]

hey @tknickman , does this change now with deno v2 ? i know deno.lock file's exist now along with workspaces / monorepo support but not sure what "monorepo support" actually means here.

[amitav13]

Hey @amitav13, thanks for the issue. This is something that isn't immediately on the roadmap. Deno is pretty different in that there is no package manager or lockfile - everything is url based. Even the common standard of storing and exporting dependencies from deps.ts and dev_deps.ts is just a convention, and not enforced. This would make integrating turborepo difficult as the dependency paradigm is quite different.

I'll leave this issue open so we can continue to gauge interest from the community, but as of now it's not something we're planning on in the short term.

Yeah I get that, its a hard one to pull in. I don't believe Nx or any other monorepo tool is supporting this atm. Would still be great to have though, we're just copy/pasting with a loud comment to remember to update in 2 places 😅

[lishaduck]

I'd like to note that my use case for a Deno Turbo is simpler, but still unsupported: I'd like a Single-package workspaces, which wouldn't require dealing with workspaces. However, the Multi-language support guide doesn't work, as Deno has heuristics that are changed in the presence of a package.json.
If we could, i.e., define tasks in turbo.json, or, better yet, use tasks from deno.json, then this would be sufficient for many Deno use cases.

Additionally, the upcoming Deno 2 will stabilize native workspace functionality, which may help monorepo use cases: denoland/deno#22942, and denoland/deno#24163 might make a package.json for scripts feasible.

[lishaduck]

Deno 2.1 is out now, with features based on Google's Wireit (task dependencies, recursive runs) and plans to take on Turborepo natively soon (with caching).

[iharuya]

Deno currently implements it on its own.
And yeah I hope we have caching as discussed here in the future :)

[lishaduck]

And yeah I hope we have caching as discussed here in the future :)

For future reference, I think the canonical issue for caching is denoland/deno#26993.

[oneezy]

deno v2 support monorepos now. does this mean it will work with deno? i havent attempted it .. just doing some research.

[lishaduck]

As I said above, the Turborepo team recommends using the Node-compat layer, while the Deno team recommends waiting on native Deno support.

[oneezy]

@lishaduck you see this?
https://x.com/JLarky/status/1859694001705844986

[lishaduck]

I'm not on X, but yeah. It doesn't support caching, but otherwise you can just use native Deno support.

[oneezy]

@lishaduck is this the magic bullet?

"feat(unstable): support caching npm dependencies only as they're needed (denoland/deno#27300)"

[lishaduck]

@lishaduck is this the magic bullet?

"feat(unstable): support caching npm dependencies only as they're needed (denoland/deno#27300)"

Nope that PR, while welcome, just enables granular "nodeModulesDir": "auto" for "npm:*" dependencies.