Is there a way to do monorepo with jsr?

[AugustinMauroy]

Is there a way to do monorepo with jsr ???

to have something like that

my-repo/
├─ example/
│  ├─ new_file
├─ @scope/package/
├─ .gitignore
├─ jsr.json
├─ README.md

So example should import package such as form JSR but code is on local.

[lucacasonato]

Yes, you can use Deno workspaces. In the root of your repository, add a deno.json containing workspaces: ["example/", "@scope/package/"]. In each of your packages, add a deno.json containing your JSR configuration for that package (name, version, exports).

You can then run deno publish at the root of the workspace to publish all packages in the workspace.

[AugustinMauroy]

and does it work with npm workspace or similar?

[MasterKale]

Is there a "correct" way, then, to reference a monorepo's package1 in package2's deno.json > "imports" in a way that'll support deno publish? When I try to use a relative path in "imports" then I get a "failed resolving" error:

package2/deno.json

{
  "name": "package2",
  "version": "1.0.0-alpha1",
  "exports": {
    ".": "./src/index.ts",
    "./helpers": "./src/helpers/index.ts"
  },
  "imports": {
    "package1": "../types/src/index.ts"
  }
}

$ deno publish
Publishing a workspace...
Checking for slow types in the public API...
Publishing [email protected] ...
error: Failed to publish [email protected]

Caused by:
    Failed to publish package2 at 1.0.0-alpha1: failed to generate documentation: Failed resolving '../../../../types/src/index.ts' from 'file:///src/helpers/foo.ts'.
    
    Stack backtrace:
       0: anyhow::error::<impl core::convert::From<E> for anyhow::Error>::from
       1: registry_api::docs::generate_docs
       2: registry_api::analysis::analyze_package_inner::{{closure}}::{{closure}}
       3: <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll
       4: <core::pin::Pin<P> as core::future::future::Future>::poll
       5: tokio::runtime::scheduler::current_thread::Context::enter
       6: tokio::runtime::context::scoped::Scoped<T>::set
       7: tokio::runtime::context::set_scheduler
       8: tokio::runtime::scheduler::current_thread::CoreGuard::block_on
       9: tokio::runtime::context::runtime::enter_runtime
      10: tokio::runtime::runtime::Runtime::block_on
      11: registry_api::analysis::analyze_package
      12: std::panicking::try
      13: tokio::runtime::task::harness::Harness<T,S>::poll
      14: tokio::runtime::blocking::pool::Inner::run
      15: std::sys_common::backtrace::__rust_begin_short_backtrace
      16: core::ops::function::FnOnce::call_once{{vtable.shim}}
      17: std::sys::pal::unix::thread::Thread::new::thread_start
      18: <unknown>
      19: <unknown>

Now I'm thinking there needs to be a step in here to replace that relative import path with jsr:package1 identifier instead, so that deno publish and JSR can find jsr:package1 instead. But maybe there's something built-in I'm not considering?