-
Notifications
You must be signed in to change notification settings - Fork 5.8k
fix(compile): wasm files might not be a part of module graph #31457
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
fix(compile): wasm files might not be a part of module graph #31457
Conversation
WalkthroughInternal helper predicates in the compile module are renamed for clarity: Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used📓 Path-based instructions (2)cli/tools/**/*.rs📄 CodeRabbit inference engine (CLAUDE.md)
Files:
**/*.rs📄 CodeRabbit inference engine (CLAUDE.md)
Files:
🧠 Learnings (1)📚 Learning: 2025-11-24T16:19:37.808ZApplied to files:
🧬 Code graph analysis (1)cli/tools/compile.rs (1)
🔇 Additional comments (3)
Comment |
| let initial_cwd = cli_options.initial_cwd(); | ||
|
|
||
| fn is_module_graph_module(url: &ModuleSpecifier) -> bool { | ||
| fn is_module_graph_root_module(url: &ModuleSpecifier) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renamed for proper semantics: Wasm files might be a module graph modules, but they are never a module graph roots
This function is only used to determine roots
| | MediaType::Html | ||
| | MediaType::Jsonc | ||
| | MediaType::Json5 | ||
| | MediaType::Json |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have an issue with json files, but they should not be part of module graph unless being imported either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
cli/tools/compile.rs (1)
356-381: Convert doc comments (///) to regular comments (//) in theMediaType::Wasmmatch arm to avoid compiler warningsThe
///lines beforeMediaType::Wasmare doc comments inside a function body. Rust's compiler warns aboutunused_doc_commentsbecause doc comments are only for documentation items (functions, structs, etc.), not statements. Use regular comments instead.Suggested change:
- /// Wasm is never a module graph root, and might be used outside of an import statement, - /// fetched() wasm files have their dependencies specified explicitly on instantiation. + // Wasm is never a module graph root, and might be used outside of an import statement. + // fetch()'d wasm files have their dependencies specified explicitly on instantiation. MediaType::Wasm => false,
🧹 Nitpick comments (1)
cli/tools/compile.rs (1)
349-355: Confirm intended behavior for non-file wasm--includeURLsThe new helpers correctly prevent local
.wasmfiles (and wasm under included directories) from becoming module graph roots while still being present ininclude_paths, which addresses the reported issue for file-based includes.However,
is_module_graph_root_modulereturnstruefor all non-fileschemes, so something like--include=https://example.com/foo.wasmwould still make that wasm a graph root and subject to import analysis. That preserves existing behavior but means the fix is scoped to file-based includes only.If you also want remote or other non-file
.wasmincludes to avoid module-graph import analysis, you could consider delegating tois_module_graph_root_media_type(MediaType::from_specifier(url))for non-file schemes as well (or special-case wasm there).Please double-check that limiting the change to file-based wasm includes matches the desired behavior for
deno compile --includeand that there are no user scenarios relying on remote wasm includes being treated as module graph roots.Also applies to: 427-433
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
cli/tools/compile.rs(3 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
cli/tools/**/*.rs
📄 CodeRabbit inference engine (CLAUDE.md)
CLI tools should be implemented in
cli/tools/<tool>orcli/tools/<tool>/mod.rs
Files:
cli/tools/compile.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 uselldbdirectly
Useeprintln!()ordbg!()macros for debug prints in Rust code
Files:
cli/tools/compile.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/tools/compile.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 release linux-x86_64
- GitHub Check: test debug windows-x86_64
- GitHub Check: test debug linux-aarch64
- GitHub Check: test debug linux-x86_64
- GitHub Check: test debug macos-aarch64
- GitHub Check: test debug macos-x86_64
- GitHub Check: lint debug windows-x86_64
- GitHub Check: lint debug macos-x86_64
- GitHub Check: lint debug linux-x86_64
- GitHub Check: build libs
76068b2 to
cc9e180
Compare
|
Was testing this change, and have encountered that fetching wasm doesn't work, as it seems like fetch() with file urls does not support reading files from DenoRtSys This does not affect utility of this patch for cases when the wasm files are only used for frontend asset storage purposes, and if someone wants to use wasm file in deno itself - it is still possible by using |
dsherret
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The two_times_compile_include_all test is now failing. Can you update the expectation?
Also, can you add a test for this in the tests/specs/compile folder? Just add a folder like some of the other tests, then run cargo test specs::compile to run the tests in that folder.
Fixes: #31456
deno compile analyzes all --included files as module graph roots, however wasm files might not be used in module graph at all, and instead
fetch()ed andWebAssembly.instantiated, in which case their imports should not be analyzed.It should not break imported wasm files, as they will be added to module graph as a dependency anyway.