Substance walks clean — two Option<bool> fields plumbed through FmtOptionsConfig → SerializedFmtConfig → workspace merge → JSON schema → dprint config builder, with a spec test that exercises both the default sort behavior and the disabled-via-config behavior.

What I verified

• SortOrder::CaseInsensitive ↔ SortOrder::Maintain mapping in cli/tools/fmt.rs:1454-1467 matches the actual dprint-plugin-typescript option semantics. CaseInsensitive is what dprint already uses by default; Maintain preserves source order. The body text says "opt out of dprint's case-insensitive sort," so Maintain is the right value when sort_named_imports: false is set.
• Default true in the JSON schema means existing deno fmt users see no change in behavior — the only way the new sort behavior fires is if a user explicitly sets false. ✓
• Workspace merging at libs/config/workspace/mod.rs:2106-2123 uses the standard member_config.or(root_config) pattern, so child workspace members override root. Consistent with how every other FmtOptionsConfig field merges. ✓
• is_default() updated to include the two new fields — important so FmtOptionsConfig::is_default() returns true when neither is set, preventing spurious config-changed reports. ✓
• malformed_config/error.out updated to include sortNamedImports/sortNamedExports in the expected one of list — the deserializer correctly rejects unknown fields and lists known ones. ✓
• Spec test design: preserves_order_when_disabled uses the new config and --check to assert no formatting needed; sorts_by_default uses --no-config and asserts --check fails (exit code 1). Both halves of the toggle exercised cleanly.

Holding COMMENT for two reasons

1. CI is blocked on maintainer authorization

mergeable_state: blocked, and the workflow run from 2026-04-17 is conclusion: "action_required" — a first-time-contributor PR needs a maintainer to authorize the CI workflow before it'll run. Currently only license/cla (passed) and lint title (passed) have status. Build / test / spec shards haven't executed at all.

Without CI, I can't confirm the JSON schema is well-formed (the schema validator runs in CI), the cargo test -p deno_config --lib fmt parse test passes, or that the new spec test actually runs cleanly. Worth pinging a maintainer to authorize the workflow run so CI can land.

2. Escalation: two new public deno.json fmt config fields

This adds sortNamedImports and sortNamedExports as public deno.json config keys. Per fibibot's policy, new user-facing config surface — even one defaulting to true for backwards compat — warrants a maintainer's call on the field naming, the Option<bool> shape (vs e.g. "sortNamedImports": "caseInsensitive" | "maintain" | "none" for future extensibility), and the precedent for letting users opt out of more dprint defaults via similar flags. cc @bartlomieju.

Substance is APPROVE-shape pending those two — happy to come back once CI is unblocked and a maintainer signs off on the surface.

Thanks for this — the implementation is clean and well-tested, and the motivation (delegating specifier order to another formatter) is solid. One design suggestion before this lands.

The config currently exposes these as booleans (true → CaseInsensitive, false → Maintain), which drops dprint's third SortOrder variant, CaseSensitive. That matters for this PR's own motivation: Biome sorts case-sensitively (uppercase before lowercase), so with a bool a user still can't make deno fmt produce Biome's order — they can only disable sorting and run both tools.

For comparison, Prettier core doesn't sort named specifiers at all (it delegates to plugins). The Prettier sort plugins model this as two axes — importOrderSortSpecifiers (on/off) plus importOrderCaseSensitive (case sensitivity) — precisely because case-sensitive sorting is a real, wanted mode. dprint already encodes all three states in one SortOrder enum.

So I'd suggest exposing a three-way string enum that maps 1:1 onto dprint, e.g.:

{
  "fmt": {
    "sortNamedImports": "maintain" | "caseSensitive" | "caseInsensitive", // default "caseInsensitive"
    "sortNamedExports": "maintain" | "caseSensitive" | "caseInsensitive"
  }
}

This keeps current behavior as the default, covers the Biome case directly, and avoids a slightly awkward config migration later (bool → enum). It'd follow the existing pattern of enum-valued fmt options like quoteProps/proseWrap rather than the bool fields.

If you'd rather keep it a bool for simplicity, that's defensible, but then it's worth a doc note that case-sensitive ordering isn't reachable. Happy to help with either direction.

Thanks!