refactor: use deno_core::anyhow::Error in favour of deno_core::error::AnyError

[iuioiua]

Towards https://github.com/denoland/deno_core/blob/2898ad965ab1b5c616c9b6738b0b7ae046653320/core/error.rs#L29

[coderabbitai]

Walkthrough

This pull request consistently replaces use deno_core::error::AnyError; with use deno_core::anyhow::Error as AnyError; across the codebase (~100+ files), making AnyError an alias for deno_core::anyhow::Error. Most changes are import-only; a small number of places update public signatures or variant payload types so their AnyError now resolves to the anyhow-based alias. No other control flow or logic changes were introduced.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly describes the main change: replacing deno_core::error::AnyError with deno_core::anyhow::Error throughout the codebase.
Description check	✅ Passed	The description references a specific GitHub link related to deno_core error handling, which is relevant to the refactoring work done in this PR.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5215ae9 and 2a48f6d.

📒 Files selected for processing (4)

• cli/main.rs (1 hunks)
• cli/module_loader.rs (1 hunks)
• cli/rt/run.rs (1 hunks)
• cli/tools/task.rs (5 hunks)

🚧 Files skipped from review as they are similar to previous changes (2)

• cli/main.rs
• cli/rt/run.rs

🧰 Additional context used

📓 Path-based instructions (3)

cli/tools/**/*.rs

📄 CodeRabbit inference engine (CLAUDE.md)

CLI tools should be implemented in cli/tools/<tool> or cli/tools/<tool>/mod.rs

Files:

• cli/tools/task.rs

**/*.rs

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.rs: For debugging Rust code, set breakpoints in IDE debuggers (VS Code with rust-analyzer, IntelliJ IDEA) or use lldb directly
Use eprintln!() or dbg!() macros for debug prints in Rust code

Files:

• cli/tools/task.rs
• cli/module_loader.rs

---

⚙️ CodeRabbit configuration file

Don't worry about coverage of Rust docstrings. Don't be nitpicky about it. Leave it to the author's judgement if such a documentation is necessary.

Files:

• cli/tools/task.rs
• cli/module_loader.rs

cli/module_loader.rs

📄 CodeRabbit inference engine (CLAUDE.md)

Module loading and resolution is handled in cli/module_loader.rs

Files:

• cli/module_loader.rs

🧠 Learnings (1)

📚 Learning: 2025-11-24T16:19:37.808Z

Learnt from: CR
Repo: denoland/deno PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:19:37.808Z
Learning: Applies to cli/module_loader.rs : Module loading and resolution is handled in `cli/module_loader.rs`

Applied to files:

• cli/module_loader.rs

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)

• GitHub Check: test debug windows-x86_64
• GitHub Check: test debug macos-aarch64
• GitHub Check: test debug linux-x86_64
• GitHub Check: test release linux-x86_64
• GitHub Check: test debug linux-aarch64
• GitHub Check: test debug macos-x86_64
• GitHub Check: lint debug linux-x86_64
• GitHub Check: lint debug macos-x86_64
• GitHub Check: lint debug windows-x86_64
• GitHub Check: build libs

🔇 Additional comments (7)

cli/module_loader.rs (1)

33-36: Import alias change is correct—deno_core::anyhow::Error as AnyError is the direct re-export path.

The change is isolated, no old imports conflict with it, and all usages in the file are consistent. deno_core v0.373.0 clearly re-exports anyhow items based on the import patterns already present in the file.

cli/tools/task.rs (6)

57-61: execute_script now returns Result<i32, AnyError> — consistent with the alias.
No behavior change; just type path normalization.

---

264-291: run_tasks signature update is consistent; error construction already matches anyhow-style errors.
anyhow!(...) and ? propagation remain compatible with the new AnyError alias.

---

305-310: run_tasks_in_parallel / LocalBoxFuture return type update looks type-safe.
The future output stays Result<_, AnyError>, so queue.next().await + result? should behave the same.

Also applies to: 327-334

---

436-445: run_deno_task return type switch to AnyError is consistent with callers and Context usage.

---

482-491: run_npm_script return type switch to AnyError is consistent with ? propagation.

---

20-24: Import alias is correct and consistent across the codebase.
Verified: no lingering deno_core::error::AnyError usage exists in the repo. The new deno_core::anyhow::Error as AnyError pattern is the standard convention in cli/ and other modules. Change is safe.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

cli/tools/task.rs (1)

20-24: Optional: consider standardizing on AnyError in signatures for consistency. Currently some fns return deno_core::anyhow::Error directly while others use AnyError.

Also applies to: 263-311

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ee7c483 and 5215ae9.

📒 Files selected for processing (108)

• cli/args/flags.rs (1 hunks)
• cli/args/mod.rs (1 hunks)
• cli/bench/main.rs (1 hunks)
• cli/cache/cache_db.rs (1 hunks)
• cli/cache/check.rs (1 hunks)
• cli/cache/code_cache.rs (1 hunks)
• cli/cache/fast_check.rs (1 hunks)
• cli/cache/incremental.rs (1 hunks)
• cli/cache/module_info.rs (1 hunks)
• cli/cache/node.rs (1 hunks)
• cli/factory.rs (1 hunks)
• cli/file_fetcher.rs (1 hunks)
• cli/graph_container.rs (1 hunks)
• cli/graph_util.rs (1 hunks)
• cli/http_util.rs (1 hunks)
• cli/lib/standalone/virtual_fs.rs (1 hunks)
• cli/lib/util/result.rs (1 hunks)
• cli/lsp/analysis.rs (1 hunks)
• cli/lsp/client.rs (1 hunks)
• cli/lsp/code_lens.rs (1 hunks)
• cli/lsp/config.rs (1 hunks)
• cli/lsp/diagnostics.rs (1 hunks)
• cli/lsp/documents.rs (1 hunks)
• cli/lsp/jsr.rs (1 hunks)
• cli/lsp/language_server.rs (1 hunks)
• cli/lsp/lint.rs (1 hunks)
• cli/lsp/mod.rs (1 hunks)
• cli/lsp/npm.rs (1 hunks)
• cli/lsp/path_to_regex.rs (1 hunks)
• cli/lsp/registries.rs (1 hunks)
• cli/lsp/repl.rs (1 hunks)
• cli/lsp/search.rs (1 hunks)
• cli/lsp/testing/definitions.rs (1 hunks)
• cli/lsp/testing/execution.rs (1 hunks)
• cli/lsp/testing/server.rs (1 hunks)
• cli/lsp/text.rs (1 hunks)
• cli/lsp/tsc.rs (1 hunks)
• cli/lsp/urls.rs (1 hunks)
• cli/main.rs (1 hunks)
• cli/module_loader.rs (1 hunks)
• cli/npm.rs (1 hunks)
• cli/ops/jupyter.rs (1 hunks)
• cli/registry.rs (1 hunks)
• cli/rt/binary.rs (1 hunks)
• cli/rt/code_cache.rs (1 hunks)
• cli/rt/main.rs (1 hunks)
• cli/rt/run.rs (1 hunks)
• cli/standalone/binary.rs (1 hunks)
• cli/task_runner.rs (1 hunks)
• cli/tools/bench/mod.rs (1 hunks)
• cli/tools/bundle/esbuild.rs (1 hunks)
• cli/tools/bundle/html.rs (1 hunks)
• cli/tools/bundle/mod.rs (1 hunks)
• cli/tools/bundle/provider.rs (1 hunks)
• cli/tools/check.rs (1 hunks)
• cli/tools/clean.rs (1 hunks)
• cli/tools/compile.rs (1 hunks)
• cli/tools/coverage/mod.rs (1 hunks)
• cli/tools/coverage/reporter.rs (1 hunks)
• cli/tools/deploy.rs (1 hunks)
• cli/tools/doc.rs (1 hunks)
• cli/tools/fmt.rs (1 hunks)
• cli/tools/info.rs (1 hunks)
• cli/tools/init/mod.rs (1 hunks)
• cli/tools/installer/bin_name_resolver.rs (1 hunks)
• cli/tools/installer/mod.rs (1 hunks)
• cli/tools/jupyter/install.rs (1 hunks)
• cli/tools/jupyter/mod.rs (1 hunks)
• cli/tools/jupyter/server.rs (1 hunks)
• cli/tools/lint/linter.rs (1 hunks)
• cli/tools/lint/mod.rs (1 hunks)
• cli/tools/lint/plugins.rs (1 hunks)
• cli/tools/lint/reporters.rs (1 hunks)
• cli/tools/lint/rules/mod.rs (1 hunks)
• cli/tools/pm/approve_scripts.rs (1 hunks)
• cli/tools/pm/audit.rs (1 hunks)
• cli/tools/pm/cache_deps.rs (1 hunks)
• cli/tools/pm/deps.rs (1 hunks)
• cli/tools/pm/mod.rs (1 hunks)
• cli/tools/pm/outdated/mod.rs (2 hunks)
• cli/tools/publish/auth.rs (1 hunks)
• cli/tools/publish/diagnostics.rs (1 hunks)
• cli/tools/publish/graph.rs (1 hunks)
• cli/tools/publish/mod.rs (1 hunks)
• cli/tools/publish/module_content.rs (1 hunks)
• cli/tools/publish/paths.rs (1 hunks)
• cli/tools/publish/provenance.rs (1 hunks)
• cli/tools/publish/publish_order.rs (1 hunks)
• cli/tools/publish/tar.rs (1 hunks)
• cli/tools/repl/channel.rs (1 hunks)
• cli/tools/repl/editor.rs (1 hunks)
• cli/tools/repl/mod.rs (1 hunks)
• cli/tools/repl/session.rs (1 hunks)
• cli/tools/run/mod.rs (1 hunks)
• cli/tools/serve.rs (1 hunks)
• cli/tools/task.rs (1 hunks)
• cli/tools/test/mod.rs (1 hunks)
• cli/tools/upgrade.rs (1 hunks)
• cli/tools/x.rs (1 hunks)
• cli/tsc/go/setup.rs (1 hunks)
• cli/util/archive.rs (1 hunks)
• cli/util/display.rs (1 hunks)
• cli/util/extract.rs (1 hunks)
• cli/util/file_watcher.rs (1 hunks)
• cli/util/fs.rs (1 hunks)
• cli/util/text_encoding.rs (1 hunks)
• ext/bundle/src/lib.rs (1 hunks)
• ext/http/service.rs (1 hunks)

🧰 Additional context used

📓 Path-based instructions (6)

**/*.rs

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.rs: For debugging Rust code, set breakpoints in IDE debuggers (VS Code with rust-analyzer, IntelliJ IDEA) or use lldb directly
Use eprintln!() or dbg!() macros for debug prints in Rust code

Files:

• cli/http_util.rs
• cli/tools/publish/provenance.rs
• cli/tools/init/mod.rs
• cli/tools/bundle/mod.rs
• cli/tsc/go/setup.rs
• cli/cache/check.rs
• cli/tools/jupyter/install.rs
• cli/lsp/lint.rs
• cli/tools/pm/outdated/mod.rs
• cli/tools/jupyter/mod.rs
• cli/standalone/binary.rs
• cli/lib/standalone/virtual_fs.rs
• cli/graph_container.rs
• cli/lsp/search.rs
• cli/lsp/client.rs
• cli/tools/doc.rs
• cli/tools/publish/publish_order.rs
• cli/tools/compile.rs
• cli/util/file_watcher.rs
• cli/tools/x.rs
• cli/file_fetcher.rs
• cli/tools/run/mod.rs
• cli/lsp/code_lens.rs
• cli/tools/clean.rs
• cli/cache/cache_db.rs
• cli/lib/util/result.rs
• cli/tools/fmt.rs
• cli/util/text_encoding.rs
• cli/tools/lint/reporters.rs
• ext/bundle/src/lib.rs
• cli/lsp/npm.rs
• cli/lsp/config.rs
• cli/tools/pm/audit.rs
• cli/cache/fast_check.rs
• cli/tools/installer/mod.rs
• ext/http/service.rs
• cli/tools/serve.rs
• cli/lsp/testing/server.rs
• cli/tools/repl/session.rs
• cli/util/fs.rs
• cli/tools/publish/tar.rs
• cli/lsp/analysis.rs
• cli/tools/pm/deps.rs
• cli/tools/check.rs
• cli/lsp/path_to_regex.rs
• cli/tools/coverage/reporter.rs
• cli/tools/bundle/html.rs
• cli/graph_util.rs
• cli/tools/coverage/mod.rs
• cli/lsp/testing/execution.rs
• cli/lsp/urls.rs
• cli/ops/jupyter.rs
• cli/tools/bundle/esbuild.rs
• cli/tools/deploy.rs
• cli/tools/lint/linter.rs
• cli/tools/repl/editor.rs
• cli/tools/lint/rules/mod.rs
• cli/tools/pm/approve_scripts.rs
• cli/lsp/mod.rs
• cli/rt/binary.rs
• cli/tools/lint/plugins.rs
• cli/task_runner.rs
• cli/tools/task.rs
• cli/cache/incremental.rs
• cli/lsp/diagnostics.rs
• cli/tools/publish/auth.rs
• cli/npm.rs
• cli/tools/bench/mod.rs
• cli/main.rs
• cli/lsp/testing/definitions.rs
• cli/lsp/registries.rs
• cli/tools/jupyter/server.rs
• cli/util/display.rs
• cli/lsp/repl.rs
• cli/lsp/text.rs
• cli/cache/node.rs
• cli/module_loader.rs
• cli/tools/publish/paths.rs
• cli/tools/publish/mod.rs
• cli/tools/info.rs
• cli/cache/code_cache.rs
• cli/registry.rs
• cli/bench/main.rs
• cli/tools/pm/cache_deps.rs
• cli/factory.rs
• cli/tools/bundle/provider.rs
• cli/rt/code_cache.rs
• cli/tools/publish/module_content.rs
• cli/tools/lint/mod.rs
• cli/lsp/documents.rs
• cli/tools/installer/bin_name_resolver.rs
• cli/util/extract.rs
• cli/tools/repl/mod.rs
• cli/args/mod.rs
• cli/rt/main.rs
• cli/tools/pm/mod.rs
• cli/util/archive.rs
• cli/rt/run.rs
• cli/args/flags.rs
• cli/tools/test/mod.rs
• cli/tools/publish/graph.rs
• cli/tools/publish/diagnostics.rs
• cli/lsp/tsc.rs
• cli/cache/module_info.rs
• cli/lsp/language_server.rs
• cli/tools/upgrade.rs
• cli/lsp/jsr.rs
• cli/tools/repl/channel.rs

---

⚙️ CodeRabbit configuration file

Don't worry about coverage of Rust docstrings. Don't be nitpicky about it. Leave it to the author's judgement if such a documentation is necessary.

Files:

• cli/http_util.rs
• cli/tools/publish/provenance.rs
• cli/tools/init/mod.rs
• cli/tools/bundle/mod.rs
• cli/tsc/go/setup.rs
• cli/cache/check.rs
• cli/tools/jupyter/install.rs
• cli/lsp/lint.rs
• cli/tools/pm/outdated/mod.rs
• cli/tools/jupyter/mod.rs
• cli/standalone/binary.rs
• cli/lib/standalone/virtual_fs.rs
• cli/graph_container.rs
• cli/lsp/search.rs
• cli/lsp/client.rs
• cli/tools/doc.rs
• cli/tools/publish/publish_order.rs
• cli/tools/compile.rs
• cli/util/file_watcher.rs
• cli/tools/x.rs
• cli/file_fetcher.rs
• cli/tools/run/mod.rs
• cli/lsp/code_lens.rs
• cli/tools/clean.rs
• cli/cache/cache_db.rs
• cli/lib/util/result.rs
• cli/tools/fmt.rs
• cli/util/text_encoding.rs
• cli/tools/lint/reporters.rs
• ext/bundle/src/lib.rs
• cli/lsp/npm.rs
• cli/lsp/config.rs
• cli/tools/pm/audit.rs
• cli/cache/fast_check.rs
• cli/tools/installer/mod.rs
• ext/http/service.rs
• cli/tools/serve.rs
• cli/lsp/testing/server.rs
• cli/tools/repl/session.rs
• cli/util/fs.rs
• cli/tools/publish/tar.rs
• cli/lsp/analysis.rs
• cli/tools/pm/deps.rs
• cli/tools/check.rs
• cli/lsp/path_to_regex.rs
• cli/tools/coverage/reporter.rs
• cli/tools/bundle/html.rs
• cli/graph_util.rs
• cli/tools/coverage/mod.rs
• cli/lsp/testing/execution.rs
• cli/lsp/urls.rs
• cli/ops/jupyter.rs
• cli/tools/bundle/esbuild.rs
• cli/tools/deploy.rs
• cli/tools/lint/linter.rs
• cli/tools/repl/editor.rs
• cli/tools/lint/rules/mod.rs
• cli/tools/pm/approve_scripts.rs
• cli/lsp/mod.rs
• cli/rt/binary.rs
• cli/tools/lint/plugins.rs
• cli/task_runner.rs
• cli/tools/task.rs
• cli/cache/incremental.rs
• cli/lsp/diagnostics.rs
• cli/tools/publish/auth.rs
• cli/npm.rs
• cli/tools/bench/mod.rs
• cli/main.rs
• cli/lsp/testing/definitions.rs
• cli/lsp/registries.rs
• cli/tools/jupyter/server.rs
• cli/util/display.rs
• cli/lsp/repl.rs
• cli/lsp/text.rs
• cli/cache/node.rs
• cli/module_loader.rs
• cli/tools/publish/paths.rs
• cli/tools/publish/mod.rs
• cli/tools/info.rs
• cli/cache/code_cache.rs
• cli/registry.rs
• cli/bench/main.rs
• cli/tools/pm/cache_deps.rs
• cli/factory.rs
• cli/tools/bundle/provider.rs
• cli/rt/code_cache.rs
• cli/tools/publish/module_content.rs
• cli/tools/lint/mod.rs
• cli/lsp/documents.rs
• cli/tools/installer/bin_name_resolver.rs
• cli/util/extract.rs
• cli/tools/repl/mod.rs
• cli/args/mod.rs
• cli/rt/main.rs
• cli/tools/pm/mod.rs
• cli/util/archive.rs
• cli/rt/run.rs
• cli/args/flags.rs
• cli/tools/test/mod.rs
• cli/tools/publish/graph.rs
• cli/tools/publish/diagnostics.rs
• cli/lsp/tsc.rs
• cli/cache/module_info.rs
• cli/lsp/language_server.rs
• cli/tools/upgrade.rs
• cli/lsp/jsr.rs
• cli/tools/repl/channel.rs

cli/tools/**/*.rs

📄 CodeRabbit inference engine (CLAUDE.md)

CLI tools should be implemented in cli/tools/<tool> or cli/tools/<tool>/mod.rs

Files:

• cli/tools/publish/provenance.rs
• cli/tools/init/mod.rs
• cli/tools/bundle/mod.rs
• cli/tools/jupyter/install.rs
• cli/tools/pm/outdated/mod.rs
• cli/tools/jupyter/mod.rs
• cli/tools/doc.rs
• cli/tools/publish/publish_order.rs
• cli/tools/compile.rs
• cli/tools/x.rs
• cli/tools/run/mod.rs
• cli/tools/clean.rs
• cli/tools/fmt.rs
• cli/tools/lint/reporters.rs
• cli/tools/pm/audit.rs
• cli/tools/installer/mod.rs
• cli/tools/serve.rs
• cli/tools/repl/session.rs
• cli/tools/publish/tar.rs
• cli/tools/pm/deps.rs
• cli/tools/check.rs
• cli/tools/coverage/reporter.rs
• cli/tools/bundle/html.rs
• cli/tools/coverage/mod.rs
• cli/tools/bundle/esbuild.rs
• cli/tools/deploy.rs
• cli/tools/lint/linter.rs
• cli/tools/repl/editor.rs
• cli/tools/lint/rules/mod.rs
• cli/tools/pm/approve_scripts.rs
• cli/tools/lint/plugins.rs
• cli/tools/task.rs
• cli/tools/publish/auth.rs
• cli/tools/bench/mod.rs
• cli/tools/jupyter/server.rs
• cli/tools/publish/paths.rs
• cli/tools/publish/mod.rs
• cli/tools/info.rs
• cli/tools/pm/cache_deps.rs
• cli/tools/bundle/provider.rs
• cli/tools/publish/module_content.rs
• cli/tools/lint/mod.rs
• cli/tools/installer/bin_name_resolver.rs
• cli/tools/repl/mod.rs
• cli/tools/pm/mod.rs
• cli/tools/test/mod.rs
• cli/tools/publish/graph.rs
• cli/tools/publish/diagnostics.rs
• cli/tools/upgrade.rs
• cli/tools/repl/channel.rs

ext/**/lib.rs

📄 CodeRabbit inference engine (CLAUDE.md)

Extensions should provide ops (operations) exposed to JavaScript in Rust code within ext/<extension_name>/ directories

Files:

• ext/bundle/src/lib.rs

cli/main.rs

📄 CodeRabbit inference engine (CLAUDE.md)

Main CLI entry point is in cli/main.rs and should handle command routing

Files:

• cli/main.rs

cli/module_loader.rs

📄 CodeRabbit inference engine (CLAUDE.md)

Module loading and resolution is handled in cli/module_loader.rs

Files:

• cli/module_loader.rs

cli/args/flags.rs

📄 CodeRabbit inference engine (CLAUDE.md)

CLI flag parsing should be defined in cli/args/flags.rs

Files:

• cli/args/flags.rs

🧠 Learnings (3)

📚 Learning: 2025-11-24T16:19:37.808Z

Learnt from: CR
Repo: denoland/deno PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:19:37.808Z
Learning: Applies to cli/module_loader.rs : Module loading and resolution is handled in `cli/module_loader.rs`

Applied to files:

• cli/standalone/binary.rs
• cli/graph_container.rs
• cli/tools/serve.rs
• cli/lsp/testing/server.rs
• cli/lsp/analysis.rs
• cli/lsp/repl.rs
• cli/module_loader.rs
• cli/tools/info.rs
• cli/util/extract.rs
• cli/rt/run.rs

📚 Learning: 2025-11-24T16:19:37.808Z

Learnt from: CR
Repo: denoland/deno PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:19:37.808Z
Learning: Applies to runtime/worker.rs : Worker and runtime initialization is implemented in `runtime/worker.rs`

Applied to files:

• cli/tools/serve.rs

📚 Learning: 2025-11-24T16:19:37.808Z

Learnt from: CR
Repo: denoland/deno PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:19:37.808Z
Learning: Applies to cli/args/flags.rs : CLI flag parsing should be defined in `cli/args/flags.rs`

Applied to files:

• cli/tools/check.rs
• cli/args/flags.rs

🧬 Code graph analysis (8)

cli/tools/bundle/mod.rs (1)

runtime/worker.rs (1)

• deno_core (1155-1155)

cli/tools/jupyter/mod.rs (1)

runtime/worker.rs (1)

• deno_core (1155-1155)

cli/tools/doc.rs (1)

runtime/worker.rs (1)

• deno_core (1155-1155)

ext/bundle/src/lib.rs (1)

runtime/worker.rs (1)

• deno_core (1155-1155)

cli/tools/pm/deps.rs (1)

ext/telemetry/lib.rs (12)

• deno_core (1294-1294)
• deno_core (1761-1761)
• deno_core (1787-1787)
• deno_core (1817-1817)
• deno_core (1845-1845)
• deno_core (1882-1882)
• deno_core (2202-2202)
• deno_core (2244-2244)
• deno_core (2294-2294)
• deno_core (2361-2361)
• deno_core (2396-2396)
• deno_core (2437-2437)

cli/task_runner.rs (1)

runtime/worker.rs (1)

• deno_core (1155-1155)

cli/tools/publish/mod.rs (1)

ext/telemetry/lib.rs (12)

• deno_core (1294-1294)
• deno_core (1761-1761)
• deno_core (1787-1787)
• deno_core (1817-1817)
• deno_core (1845-1845)
• deno_core (1882-1882)
• deno_core (2202-2202)
• deno_core (2244-2244)
• deno_core (2294-2294)
• deno_core (2361-2361)
• deno_core (2396-2396)
• deno_core (2437-2437)

cli/args/mod.rs (1)

runtime/worker.rs (1)

• deno_core (1155-1155)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)

• GitHub Check: test debug macos-aarch64
• GitHub Check: test debug windows-x86_64
• GitHub Check: test debug linux-aarch64
• GitHub Check: test debug macos-x86_64
• GitHub Check: lint debug windows-x86_64
• GitHub Check: test release linux-x86_64
• GitHub Check: test debug linux-x86_64
• GitHub Check: lint debug linux-x86_64
• GitHub Check: lint debug macos-x86_64
• GitHub Check: build libs

🔇 Additional comments (108)

cli/tools/jupyter/install.rs (1)

9-9: LGTM!

Clean refactoring that aligns with the PR objective. The import change maintains the AnyError alias while sourcing it directly from anyhow::Error, consistent with the other deno_core::anyhow imports already in the file.

cli/tools/installer/bin_name_resolver.rs (1)

5-5: LGTM - Import refactor is correct.

The change correctly updates the error type import to use anyhow::Error directly while maintaining the AnyError alias. This is consistent with the PR objective and has no functional impact.

cli/util/extract.rs (1)

20-20: LGTM!

The import path change is correct and maintains backward compatibility through aliasing. All existing usages of AnyError throughout the file remain unchanged.

cli/tools/jupyter/server.rs (1)

16-16: LGTM - clean import refactor.

The change correctly aliases anyhow::Error as AnyError, maintaining compatibility with all existing usages in the file.

cli/tools/init/mod.rs (1)

13-13: LGTM!

The import path change is correct and preserves all existing usage of AnyError throughout the file. This aligns with the PR's objective to use the anyhow error type directly instead of through the deno_core error module alias.

cli/tools/repl/session.rs (1)

26-27: This change is part of an intentional codebase-wide refactor (commit 5215ae9) migrating from deno_core::error::AnyError to deno_core::anyhow::Error directly. The systematic migration across multiple files confirms this is an approved architectural change in deno_core, not a risky swap. No further verification needed.

cli/tools/x.rs (1)

11-11: LGTM – Clean refactor with no functional impact.

The import path change from deno_core::error::AnyError to deno_core::anyhow::Error as AnyError maintains the same alias name throughout the file, so all function signatures and error handling remain unchanged. This aligns with the codebase-wide refactor described in the PR.

cli/util/text_encoding.rs (1)

9-9: LGTM!

The import refactor is clean and maintains compatibility through aliasing.

cli/cache/module_info.rs (1)

7-7: LGTM - Clean import path refactoring.

The switch from deno_core::error::AnyError to deno_core::anyhow::Error as AnyError maintains the same alias while using the anyhow re-export directly. No functional changes.

cli/tsc/go/setup.rs (1)

8-8: LGTM - Consistent with PR refactoring.

Import path updated while preserving the AnyError alias. No changes to error handling logic.

cli/tools/publish/mod.rs (1)

20-20: LGTM - Import refactoring applied correctly.

The error type import path is updated consistently with the repository-wide refactoring. All existing AnyError usages remain unchanged.

cli/tools/publish/module_content.rs (1)

12-12: LGTM - Straightforward import update.

Error type alias updated to use anyhow re-export directly. No impact on functionality.

cli/lsp/search.rs (1)

5-5: LGTM - Import path refactored correctly.

The AnyError alias now points to anyhow::Error via deno_core's re-export. Trait definitions remain unchanged.

cli/tools/publish/publish_order.rs (1)

9-9: LGTM - Clean refactoring.

Import path updated while maintaining the AnyError alias. No functional impact.

cli/tools/doc.rs (1)

11-11: LGTM - Import refactoring complete.

Error type alias updated to use anyhow's Error directly through deno_core. No changes to error handling logic or function signatures.

cli/cache/incremental.rs (1)

7-7: LGTM - Import path updated correctly.

The error type alias now references anyhow::Error via deno_core's re-export. Cache functionality remains unchanged.

cli/http_util.rs (1)

7-7: LGTM!

Clean mechanical import update. The alias preserves API compatibility across the file.

cli/tools/bundle/mod.rs (1)

28-28: LGTM!

Import path updated consistently. The file already uses deno_core::anyhow::anyhow! directly elsewhere, so this aligns the error type sourcing.

cli/tools/lint/linter.rs (1)

14-16: LGTM!

Good alignment - now both Context and Error (aliased as AnyError) come from the same deno_core::anyhow module.

cli/tools/pm/outdated/mod.rs (2)

10-11: LGTM!

Consistent with the existing bail import from the same module.

---

555-557: LGTM!

Nested filter module now sources all anyhow-related imports (Context, Error as AnyError, anyhow) from the same path.

cli/util/fs.rs (1)

14-16: LGTM!

All anyhow-related imports (Context, Error as AnyError, anyhow) now consistently sourced from deno_core::anyhow.

cli/rt/run.rs (1)

21-21: Straightforward import swap; keeps Result<_, AnyError> intact.

cli/lsp/testing/server.rs (1)

9-9: Looks good: LSP testing now uses the same anyhow-based AnyError.

cli/tools/lint/plugins.rs (1)

13-15: Nice alignment: AnyError + bail! now clearly come from the same anyhow lineage.

cli/lsp/testing/execution.rs (1)

11-13: Good: AnyError matches anyhow!(...) usage here.

cli/graph_util.rs (1)

13-13: Import change is consistent with the PR goal; signatures remain the same.

cli/util/archive.rs (1)

8-11: Good cleanup: Context/bail! and AnyError are now all from deno_core::anyhow.

cli/task_runner.rs (1)

10-12: Looks right: keeps Context + AnyError consistent and avoids deno_core::error::AnyError.

cli/lib/util/result.rs (1)

9-9: Import migration is clean. No old error module imports remain, and the AnyError alias is consistently applied across the codebase pointing to anyhow::Error. The CoreError downcasts will work correctly since both types come from the same deno_runtime::deno_core re-export.

cli/file_fetcher.rs (1)

14-14: LGTM - Import path refactoring is correct.

The change to use deno_core::anyhow::Error as AnyError is a straightforward refactoring that preserves the alias name, keeping all existing code compatible.

cli/tools/bundle/provider.rs (1)

9-9: LGTM - Consistent with the error type refactoring.

cli/lsp/lint.rs (1)

9-9: LGTM.

cli/npm.rs (1)

10-10: LGTM.

cli/module_loader.rs (1)

34-34: LGTM.

cli/factory.rs (1)

14-14: LGTM.

cli/cache/cache_db.rs (1)

8-8: LGTM.

cli/tools/publish/provenance.rs (1)

13-13: LGTM.

cli/tools/coverage/reporter.rs (1)

6-6: LGTM; no naming collision with std::io::Error. Keeping the alias as AnyError avoids clashing with the existing use std::io::Error;.

Also applies to: 12-12

cli/tools/check.rs (1)

5-5: Straightforward alias swap; looks fine.

Also applies to: 14-18

cli/tools/pm/audit.rs (1)

6-8: Looks good; aligns with Context usage already coming from deno_core::anyhow.

Also applies to: 29-33

cli/tools/publish/paths.rs (1)

12-12: LGTM; this file treats AnyError purely as a Result error type.

Also applies to: 232-235

cli/tools/serve.rs (1)

7-10: The AnyError::from conversions are idiomatic and should type-check fine. The code uses standard error handling with anyhow::Error, which has broad From implementations for common error types. Lines 131–133 properly map errors in the try_join! call, and lines 108/166 consistently use Into::into for worker results. No type-checking issues expected here.

cli/tools/publish/graph.rs (1)

10-10: The import change is correct and matches the codebase standard. deno_core::anyhow::Error as AnyError is used consistently throughout the entire project (100+ files follow this pattern), and no legacy imports remain. The file properly uses the AnyError alias in its function signature.

cli/tools/run/mod.rs (1)

9-11: Verified: AnyError::msg() call sites are compatible with the anyhow::Error alias. The anyhow::Error::msg() method exists and accepts Display + Debug + Send + Sync + 'static types. All five usages in this file (lines 352, 355, 362, 367, 369) pass format!() results or string literals, which satisfy the trait bounds. No conflicting AnyError imports found. The import alias change is safe.

cli/tools/publish/diagnostics.rs (1)

21-21: LGTM - Clean import path update.

The change from deno_core::error::AnyError to deno_core::anyhow::Error as AnyError is straightforward and maintains the existing API surface.

cli/tools/pm/deps.rs (1)

14-14: LGTM - Consistent with repo-wide refactor.

Import path updated correctly while preserving the AnyError alias.

cli/standalone/binary.rs (1)

21-21: LGTM - Import path updated correctly.

cli/graph_container.rs (1)

8-8: LGTM - Import updated correctly.

cli/main.rs (1)

43-43: LGTM - Main entry point import updated correctly.

cli/tools/jupyter/mod.rs (1)

6-6: LGTM - Import path updated correctly.

cli/lib/standalone/virtual_fs.rs (1)

19-19: LGTM - Import path updated correctly.

Note that this uses deno_runtime::deno_core::anyhow::Error which is appropriate given this file's import patterns (it consistently accesses deno_core through deno_runtime).

cli/tools/repl/editor.rs (1)

15-15: LGTM - Import path updated correctly.

cli/tools/pm/cache_deps.rs (1)

8-8: LGTM: import swap keeps the AnyError surface while using the anyhow-backed type.
Only thing to double-check is that deno_core::anyhow::Error is the intended stable re-export for this repo revision (so downstream crates don’t rely on deno_core::error::AnyError specifically).

cli/tools/coverage/mod.rs (1)

17-18: Looks correct; AnyError::from usage should still compile with anyhow::Error.
Recommend running a quick cargo check / workspace build to ensure no modules depended on deno_core::error::AnyError as a distinct alias.

Also applies to: 403-410

cli/tools/info.rs (1)

9-9: LGTM: consistent AnyError aliasing with the PR objective.
Please verify there’s no remaining mixed usage in this module (or feature-gated code) that expects deno_core::error::AnyError.

cli/rt/binary.rs (1)

15-18: LGTM: aligns AnyError with deno_core::anyhow::Error, and the existing Context/bail! patterns still match.
Just ensure CI covers all targets here (esp. the Windows #[cfg(windows)] paths) since this file is pretty platform-sensitive.

cli/tools/clean.rs (1)

12-16: LGTM: alias swap is consistent, including the url_to_path callback signature.
Worth verifying there’s no type inference edge-case where the older alias path mattered (should be unlikely, but easy to confirm via cargo check).

Also applies to: 422-427

cli/tools/compile.rs (1)

12-16: LGTM: this file already leans heavily on anyhow patterns, so the alias change is especially clean here.
Please verify the workspace still compiles with the target deno_core revision that exposes deno_core::anyhow::Error.

cli/lsp/testing/definitions.rs (1)

3-5: LGTM: simple alias swap; return type stays Result<_, AnyError>.
As a sanity check, ensure no other LSP testing modules still import deno_core::error::AnyError (avoid churn / mixed patterns).

Also applies to: 147-157

cli/cache/check.rs (1)

3-5: LGTM: error type resolution change should be transparent for these DB helper results.
Please verify the ? conversions still behave the same in this crate (they should, but this is dependency/API-surface territory).

Also applies to: 57-65

cli/tools/upgrade.rs (1)

18-18: LGTM! Clean import path update.

The change from deno_core::error::AnyError to deno_core::anyhow::Error as AnyError maintains the same alias and type, ensuring no impact on function signatures or runtime behavior.

cli/tools/bundle/html.rs (1)

11-11: LGTM! Consistent refactor.

Import path correctly updated to use deno_core::anyhow::Error as AnyError.

cli/tools/installer/mod.rs (1)

20-20: LGTM! Error type alias updated correctly.

The import path change aligns with the project-wide refactor to use anyhow::Error directly.

cli/tools/lint/rules/mod.rs (1)

10-10: LGTM! Import update applied correctly.

cli/tools/lint/mod.rs (1)

21-21: LGTM! Error import path updated.

cli/tools/deploy.rs (1)

6-6: LGTM! Clean refactor.

cli/lsp/urls.rs (1)

10-10: LGTM! Import path correctly updated.

cli/cache/fast_check.rs (1)

3-3: LGTM! Final import path update.

All files in this review consistently apply the refactor from deno_core::error::AnyError to deno_core::anyhow::Error as AnyError. The changes are clean and maintain API compatibility.

cli/tools/repl/mod.rs (1)

7-7: Import swap looks consistent with the PR goal; just verify the re-export is stable.
This is a straightforward alias change and should remain source-compatible here. Please confirm deno_core::anyhow::Error is the intended long-term re-export (and that no feature-gating affects it) by running a local cargo check.

cli/rt/code_cache.rs (1)

12-14: LGTM; alias keeps signatures intact, and bail! stays in the same module.
Nothing else in this file appears sensitive to the concrete error type, but this still depends on deno_core::anyhow re-exporting Error consistently—please verify via cargo check.

cli/tools/lint/reporters.rs (1)

4-6: Looks safe; please double-check JS error downcasting still behaves as expected.
js_error_downcast_ref(err) should still work if errors are being stored in anyhow::Error consistently, but since this is a cross-crate type-source change, verify with cargo test -p deno_cli lint (or at least cargo check).

cli/tools/publish/tar.rs (1)

7-9: No issues; Context + Error as AnyError combo is coherent.
Given this relies on deno_core::anyhow re-exports, please validate with cargo check (and ideally a publish-related test run).

cli/util/file_watcher.rs (1)

13-18: Change is fine; recommend a quick watch-mode smoke test because errors are user-facing.
Even if this is “just” an import swap, the displayed formatting ({err:?}) and JS error downcast path are UX-critical—please run cargo check plus a minimal deno run --watch smoke test.

cli/cache/node.rs (1)

3-4: LGTM; ensure_ok(Result<_, AnyError>) remains source-compatible.
Since this shifts the concrete AnyError origin, please verify with cargo test -p deno_cli cache::node (or nearest suite) / cargo check.

cli/cache/code_cache.rs (1)

4-6: Looks good; just verify the trait boundary still compiles cleanly.
Because this is a trait-impl boundary using Result<_, AnyError> internally, please confirm with cargo check / targeted tests to ensure no hidden type alias mismatch occurs across crates.

cli/lsp/tsc.rs (1)

27-29: Import swap is consistent; please run LSP-related checks because this file is a big fan-out.
This module sends AnyError across channels/threads and uses it pervasively; even though it’s intended to be equivalent, this is the place where any alias mismatch will hurt most—please verify with cargo check + whatever LSP/tsc test suite you normally run.

cli/tools/fmt.rs (1)

27-27: LGTM - Clean refactor to anyhow-based error type

The import change correctly aliases deno_core::anyhow::Error as AnyError, maintaining compatibility with all existing usages in the file. No functional changes.

cli/tools/pm/mod.rs (1)

10-10: LGTM - Consistent with repo-wide error type standardization

The import change maintains the AnyError alias while switching to the anyhow-based implementation. All existing Result<_, AnyError> types continue to work without modification.

cli/tools/bench/mod.rs (1)

11-11: LGTM - Error type import updated correctly

The change aligns with the project-wide shift to anyhow-based error handling while preserving the AnyError alias for backward compatibility.

cli/tools/publish/auth.rs (1)

6-6: LGTM - Auth module error handling updated

Import path correctly updated to use anyhow-based error type. Function signatures using Result<_, AnyError> remain unchanged.

cli/ops/jupyter.rs (1)

12-12: LGTM - Jupyter ops error handling aligned

Import correctly updated. The JupyterBroadcastError::ZeroMq variant continues to use AnyError, which now resolves to the anyhow-based type without breaking the public API.

cli/tools/repl/channel.rs (1)

5-5: LGTM - REPL channel error handling updated

The import change is consistent with the broader refactor. All Result<_, AnyError> usages continue to work as expected.

cli/util/display.rs (1)

5-5: LGTM - Display utilities error handling standardized

Import path updated correctly. The write_json_to_stdout function signature remains unchanged while benefiting from the anyhow-based error type.

cli/tools/test/mod.rs (1)

34-34: LGTM - Test infrastructure error handling aligned

The import change correctly updates to anyhow-based error handling while preserving the AnyError alias. The separate imports for anyhow macro (line 33, 35) are correctly maintained for error construction throughout the test infrastructure.

ext/http/service.rs (1)

808-808: Test signature update looks correct; keeps error handling flexible.
Switching the test to Result<(), deno_core::anyhow::Error> should keep ? ergonomics unchanged.

cli/lsp/repl.rs (1)

8-10: Alias change is clean; call sites should behave the same.

cli/lsp/client.rs (1)

6-9: Good migration step; aligns AnyError with anyhow!/bail! usage.

cli/lsp/diagnostics.rs (1)

10-13: Import update is consistent; AnyError::from call sites should continue to work.

cli/rt/main.rs (1)

7-8: Import swap seems safe for unwrap_or_exit and keeps error plumbing simple.

ext/bundle/src/lib.rs (1)

8-45: Trait + default impl now consistently use deno_core::anyhow error types.

cli/lsp/config.rs (1)

26-29: Clean alias change; matches the file’s existing anyhow! usage.

cli/args/mod.rs (1)

36-36: Import migration is complete and consistent. No old deno_core::error::AnyError imports remain in the repository. The new AnyError alias from deno_core::anyhow::Error is used consistently throughout the file in all function signatures.

cli/lsp/text.rs (1)

1-4: No issues with the AnyError import and error handling. The alias correctly points to deno_core::anyhow::Error, and self.inner.offset() already returns the matching error type, so conversions work cleanly.

cli/lsp/language_server.rs (1)

21-25: The import change is safe. No stray references to the old deno_core::error::AnyError pattern exist anywhere in the codebase, and the new alias use deno_core::anyhow::Error as AnyError on line 22 is properly in place. Error conversions in the file (Result<_, AnyError> return types) will work correctly with this alias since it directly points to anyhow::Error, the underlying error type that supports the ? operator conversions.

cli/lsp/jsr.rs (1)

7-10: LGTM. deno_core::anyhow is consistently re-exported across the entire codebase without feature gating. This import pattern is used throughout cli/lsp/ and other modules.

cli/lsp/code_lens.rs (1)

14-16: No issues with this import change. The code already uses deno_core::anyhow::Error as AnyError and it compiles fine. Since deno_core re-exports anyhow, both the old and new import paths resolve to the same type. The change is safe; AnyError is only used internally in function return types, not in public API signatures.

cli/lsp/npm.rs (1)

5-9: Reconsider using deno_core::error::AnyError instead of re-aliasing deno_core::anyhow::Error.

The code imports deno_core::anyhow::Error as AnyError, but deno_core's error module (deno_core::error::AnyError) is the documented stable public type. Aliasing the raw anyhow export diverges from the recommended pattern and may create confusion for maintainers. deno_core::error::AnyError is not deprecated and remains the preferred downstream error type.

cli/args/flags.rs (1)

40-43: Import swap looks correct; please confirm alias equivalence across deno_core versions. The local AnyError name is preserved, so this should be safe as long as deno_core::anyhow::Error is always available (no cfg/feature gating) and matches the old deno_core::error::AnyError semantics.

cli/lsp/registries.rs (1)

10-12: Looks good: consistent AnyError aliasing via deno_core::anyhow::Error.
This should stay behavior-neutral while aligning with the PR goal.

cli/lsp/documents.rs (1)

21-26: Import swap is fine; keep an eye on type identity across crate boundaries.
If anything depends on the concrete path deno_core::error::AnyError (vs the alias), it’ll show up as trait-bound/From impl compile errors.

cli/lsp/path_to_regex.rs (1)

34-36: LGTM: aligns AnyError with anyhow! usage in this module.

cli/tools/pm/approve_scripts.rs (1)

10-14: Good change: makes the file’s error type match its anyhow-style APIs.

cli/lsp/analysis.rs (1)

14-18: LGTM: consistent with the repo-wide AnyError migration.

cli/tools/bundle/esbuild.rs (1)

6-9: Good: error type now matches the anyhow-based control flow here (Context, bail!).

cli/lsp/mod.rs (1)

3-3: LGTM: keeps start() signature stable while switching the backing error type.

Also applies to: 42-42

cli/bench/main.rs (1)

16-16: Looks good: the local Result<T> alias stays consistent with the updated AnyError import.

Also applies to: 492-492

cli/registry.rs (1)

3-3: LGTM - Clean refactor to use anyhow::Error directly.

The import change is correct. Since deno_core::error::AnyError is already a type alias for anyhow::Error, this just uses the underlying type directly. No behavior changes, and the usage at line 141 remains compatible.

[dsherret]

I actually preferred AnyError because it was clear.