denoland / deno

A modern runtime for JavaScript and TypeScript.
https://deno.com
MIT License
97.18k stars 5.37k forks source link

Deno panic when configuring import with file:// in workspace #26089

Open mattjennings opened 3 weeks ago

mattjennings commented 3 weeks ago

I might be totally misconfiguring things. Saw the Deno 2.0 announcement and decided to try migrating a small npm monorepo to Deno, but ran into a panic when configuring an import to another project in the workspace.

Repro:

Output:

RUST_BACKTRACE=1 deno run dev
Task dev deno run --watch main.ts
Watcher Process started.

============================================================
Deno has panicked. This is a bug in Deno. Please report this
at https://github.com/denoland/deno/issues/new.
If you can reliably reproduce this panic, include the
reproduction steps and re-run with the RUST_BACKTRACE=1 env
var set and include the backtrace in your report.

Platform: macos aarch64
Version: 2.0.0
Args: ["/Users/mattjennings/.deno/bin/deno", "run", "--watch", "main.ts"]

thread 'main' panicked at cli/graph_util.rs:1001:48:
called `Result::unwrap()` on an `Err` value: ()
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: <deno::graph_util::FileWatcherReporter as deno_graph::source::Reporter>::on_load
   4: deno_graph::graph::Builder::fill::{{closure}}
   5: deno_graph::graph::ModuleGraph::build::{{closure}}
   6: deno::graph_util::ModuleGraphBuilder::build_graph_with_npm_resolution::{{closure}}
   7: deno::module_loader::ModuleLoadPreparer::prepare_module_load::{{closure}}
   8: <deno::module_loader::CliModuleLoader<TGraphContainer> as deno_core::modules::loaders::ModuleLoader>::prepare_load::{{closure}}
   9: deno_core::modules::recursive_load::RecursiveModuleLoad::prepare::{{closure}}
  10: deno::worker::CliMainWorker::execute_main_module_possibly_with_npm::{{closure}}
  11: deno::worker::CliMainWorker::run_for_watcher::{{closure}}
  12: deno::tools::run::run_script::{{closure}}
  13: deno::spawn_subcommand::{{closure}}
  14: <deno_unsync::tokio::task::MaskFutureAsSend<F> as core::future::future::Future>::poll
  15: tokio::runtime::task::raw::poll
  16: deno::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

This is from a file:// import in example/deno/deno.json

"imports": {
    "game-engine": "file://../../packages/game-engine"
  }

Removing file:// avoids the panic, but it still fails to find the project, so I'm probably misconfiguring something here.

Let me know if there's any more info you need.

mattjennings commented 3 weeks ago

ah, it appears imports for workspace projects don't need to be defined as per https://docs.deno.com/runtime/fundamentals/workspaces/. That solves my initial problem at least.


Just some small documentation feedback since I missed it on the first read, I think this part

In the add/ subdirectory, we define a deno.json with a "name" field, which is important for referencing the workspace member.

would be worth changing to highlight imports are automatically setup using these too, as it was this block further down that finally clarified it to me

  1. By using name and version options in members' deno.json files, it's possible to refer to them using "bare specifiers" across the whole workspace. In this case, the packages are named @scope/add and @scope/subtract, where scope is the "scope" name you can choose. With these two options, it's not necessary to use long and relative file paths in import statements.