feat: add deno transpile subcommand - #32691

Picked this up after @dsherret's CHANGES_REQUESTED. The arg-parse tests have been added and most of the path-handling/error-context items addressed; the open architectural item (use TypeChecker rather than calling tsc::exec directly from a tool) is still pending and dsherret offered to refactor — defer to him and you on that.

A handful of substance bugs I caught while reading the new code:

Bugs

Source-map filename uses with_extension("js.map") — wrong for .cts/.mts

let map_path = output_path.with_extension("js.map");

Path::with_extension replaces only the last extension component:

• out.js → out.js.map ✓
• helpers.cjs → helpers.js.map ✗ (should be helpers.cjs.map, and overwrites whatever else might be there)
• helpers.mjs → helpers.js.map ✗

Also affects the source-map ↔ output-file linkage, since the emitted .js/.cjs/.mjs will reference helpers.js.map (which doesn't exist). Pre-existing extension should be appended: output_path.with_extension(format!("{ext}.map")) where ext is what js_extension_for_media_type returned for the input's media type.

The --outdir test only uses .ts inputs (main.ts / helpers.ts), so .cts/.mts inputs aren't covered anywhere — would catch this.

EmitOptions::source_map_file set to the input basename

source_map_file: Some(
  file_path.file_name().unwrap_or_default().to_string_lossy().into_owned()
),

source_map_file controls the file field in the emitted source map JSON, which per the spec should be the generated file (the .js output), not the original .ts input. As written, the source map says it describes main.ts, but it actually describes main.js — debuggers and other consumers will key off the wrong filename. Use output_path.file_name() (or js_filename) instead.

source_map: source_map_option clobbers compilerOptions.sourceMap from deno.json

let emit_options = EmitOptions {
  source_map: source_map_option,
  source_map_file: Some(...),
  ..transpile_and_emit_options.emit.clone()
};

source_map_option is SourceMapOption::None by default (when --source-map isn't passed). That always overrides whatever the user set in deno.json compilerOptions.sourceMap / inlineSourceMap. So deno transpile main.ts silently ignores deno.json's source-map config. If the intent is "CLI flag wins when present, otherwise fall through to deno.json," the merge should be conditional:

let emit_options = if matches!(transpile_flags.source_map, SourceMapMode::None) {
    transpile_and_emit_options.emit.clone()  // honor deno.json
} else {
    EmitOptions { source_map: source_map_option, ..transpile_and_emit_options.emit.clone() }
};

(Or document explicitly that --source-map is required to enable maps from this CLI.)

emit_declarations uses only root_names[0]'s compiler options for all files

let first_specifier = &root_names[0].0;
let base_compiler_options = compiler_options_resolver
  .for_specifier(first_specifier)
  .compiler_options_for_lib(...)?;

If transpile a.ts b.ts is invoked across two folders with different deno.json scopes, only a.ts's compiler options are used to type-check both files. The non-declaration loop already does the right thing (for_specifier per-file). For declarations, since the whole graph is type-checked under one TSC pass, you'd at minimum want to error out if the root_names span multiple compiler-options scopes — silent application of the first scope's options across the rest is the kind of bug that surfaces only in monorepos.

Smaller nits

• tests/specs/transpile/__test__.jsonc doesn't cover .mts/.cts input — would have caught the .js.map extension bug.
• tests/specs/transpile/declaration_emit.out doesn't constrain the order of Emit out.js vs Emit main.d.ts. The current code emits them in two separate phases (JS first, then declarations), but consider asserting the order to lock in the user-facing console output.
• tests/specs/transpile/error_separate_sourcemap_stdout.out — the error wording "Cannot use --source-map separate when outputting to stdout. Use --output or --outdir, or use --source-map inline instead." is a clear actionable message; nice.
• Declaration code path captures .d.ts.map files in op_emit_inner (name.ends_with(".d.ts.map")) but emitDeclarationOnly: true plus no declarationMap: true means TSC won't emit .d.ts.map. Capture is harmless but unused. Set declarationMap if you want to pass through the user's setting.
• let response = tsc::exec(...) in emit_declarations ignores cli_options.type_check_mode() and forces TypeCheckMode::All. For --declaration this is correct (declarations require type-checking) but worth a comment so future readers don't get confused by the apparent flag override.

Architectural

dsherret already flagged that calling tsc::exec directly from a tool is too low-level. This revision exposes TypeChecker::create_request_npm_state as a partial fix — but the bulk of the request setup (config merging via JSON Value mutation, hash_data construction, root_names assembly) is still inline in transpile.rs. If dsherret takes the refactor he offered (move declaration emission into TypeChecker), most of the boilerplate in emit_declarations collapses, and the capture_emitted_files plumbing stops being a Request field — it becomes the difference between two TypeChecker methods.

I'd hold this PR for that refactor before merging — the current shape locks in tsc as a public-ish surface from cli/tools/.

CI

Fully green on the visible jobs. COMMENT rather than approval given the open dsherret thread + the source-map bugs above.

Every substantive item from my prior review is fixed in the new commits, and dsherret's architectural concern (calling tsc::exec directly from a tool) is fully addressed.

Fixes for my prior bugs

Source-map filename now uses output basename

// Compute the output path/filename so source_map_file references the
// generated file (e.g. "out.js"), not the input (e.g. "main.ts").
let maybe_output_path = if !is_stdout_mode { Some(...) } else { None };
let source_map_filename = if let Some(output_path) = &maybe_output_path {
  output_path.file_name().unwrap_or_default().to_string_lossy().into_owned()
} else {
  // In stdout mode, use the input-derived JS filename
  let ext = js_extension_for_media_type(*media_type);
  file_path.with_extension(ext).file_name().unwrap_or_default().to_string_lossy().into_owned()
};

The existing check_map.ts now asserts out.js (was previously asserting just version 3). ✓

with_extension("js.map") ↔ .cts/.mts fixed

let ext = output_path.extension().unwrap_or_default().to_string_lossy();
let map_path = output_path.with_extension(format!("{ext}.map"));

So out.cjs → out.cjs.map, out.mjs → out.mjs.map, out.js → out.js.map. ✓ Plus new test fixtures cts_source_map_separate and mts_source_map_separate lock this in:

"args": "transpile helper.cts -o out.cjs --source-map separate",
"output": "[WILDCARD]Emit [WILDCARD]out.cjs\nEmit [WILDCARD]out.cjs.map\n"

And check_cts_map.ts / check_mts_map.ts verify the source map's file field references the correct output filename. ✓

emit_declarations multi-scope check

Now bails with a clear error rather than silently applying the first specifier's options:

if key != first_key {
  anyhow::bail!(
    "Cannot generate declarations for files with different compiler option scopes.\n\
     '{}' uses scope '{}' but '{}' uses scope '{}'.\n\
     Separate these files into different invocations.",
    ...
  );
}

✓ Better than my suggestion (an error message that tells the user what to do), not just an internal-state validity check.

Architectural fix — TypeChecker::emit_declarations

The boilerplate that was inline in transpile.rs (config merging via JSON Value mutation, hash_data construction, tsc::exec call) has moved into a new TypeChecker::emit_declarations method:

pub fn emit_declarations(
  &self,
  graph: Arc<ModuleGraph>,
  root_names: Vec<(ModuleSpecifier, MediaType)>,
  lib: TsTypeLib,
) -> Result<EmitDeclarationsResult, CheckError>

transpile.rs now calls type_checker.emit_declarations(graph, root_names, lib)? and consumes a clean EmitDeclarationsResult { diagnostics, emitted_files }. The 60+ lines of inline TSC plumbing collapse to a single call. tsc::exec is no longer reachable from cli/tools/transpile.rs. ✓

This is exactly the shape dsherret asked for in the original CHANGES_REQUESTED. The new method's // Declaration emit requires full type-checking regardless of the user's type_check_mode setting. comment also addresses my non-blocking note about why TypeCheckMode::All is forced.

Smaller items

Still open from prior review

• declaration_emit.out still doesn't constrain the order of Emit out.js vs Emit main.d.ts. Cosmetic — won't block.
• .d.ts.map capture in op_emit_inner still unused (no declarationMap: true set). Cosmetic.

New things worth a look

• The source_map_filename computation logic now lives inline in two branches (stdout vs file mode). For stdout, it computes the would-be output filename from the input — slightly awkward since stdout mode never writes a file. The file field in the inline-source-map JSON would still claim main.js for transpile main.ts --source-map inline. That's actually correct behavior (the inline source map describes the JS that's about to land at stdout, which would conventionally be saved as main.js), so the asymmetric handling is fine. Just noting since I had to think about it.

CI

134 pass, 2 skipping, 0 fail. ✓

Verdict

Substance is now clean and complete. dsherret hasn't re-reviewed since the architectural refactor (182c056) — his original CHANGES_REQUESTED was on the inline tsc::exec shape, which is now fully resolved by the new TypeChecker::emit_declarations method. Worth pinging him for re-review since this is exactly the shape he offered to do, and he should be the one to confirm the new TypeChecker surface is what he had in mind.

Holding to COMMENT rather than approving — deno transpile is a new public CLI subcommand and the architectural refactor is in dsherret's domain, so his sign-off is the gate. From a substance-correctness standpoint, the previously-flagged bugs are all gone and CI is green.