Deno formatting options using fmt?

[yurkimus]

I know, under the hood Deno uses dprint and I wonder why there is no ability to pass any dprint-compatible configuration options when using Deno.

There was an issue fixed:

• Pass Dprint options directly from deno.json during deno fmt #26874 underlying the problem
• feat(fmt): add fmt options #28946

So, my questions here is probably more about principles and paradygm behind the solution of using certain fmt options and not just passing down any configuration to the dprint.

P.S. I am using standalone dprint configuration be cause of that.

[marvinhagemeister]

Which formatting option are you missing?

[yurkimus]

My actual typescript configured within dprint.json with the following:

{
    "arrowFunction.useParentheses": "preferNone",
    "importDeclaration.forceSingleLine": true,
    "importDeclaration.spaceSurroundingNamedImports": true,
    "indentWidth": 2,
    "lineWidth": 80,
    "quoteStyle": "preferSingle",
    "semiColons": "asi",
    "useBraces": "preferNone",
    "useTabs": false,
  }

According to the latest changes in the deno's schema configuration the missing options are:

• useParentheses
• importDeclaration.forceSingleLine
• importDeclaration.spaceSurroundingNamedImports
• quoteStyle

[mgkvibez]

Answering the design question as well as the practical one, since you asked about the principle:

The principle: deno fmt deliberately exposes a curated, stable configuration surface rather than passing dprint's full option tree through. The trade-off the team picked: a small set of options they can guarantee behave identically across Deno versions (dprint is an implementation detail — its version changes with Deno, its plugins can change defaults, and options can gain/lose meaning between plugin releases). If deno fmt forwarded arbitrary dprint config, every dprint bump could silently change your formatting, which breaks the core promise of a built-in formatter: deno fmt output is stable and boring, forever. The supported keys in deno.json are the ones that survive that contract:

{
  "fmt": {
    "lineWidth": 100,
    "indentWidth": 2,
    "singleQuote": false,
    "semicolons": true,
    "proseWrap": "always",
    "include": [...],
    "exclude": [...]
  }
}

The escape hatch is exactly what you're doing: a standalone dprint config alongside deno fmt. That's a supported pattern, not a hack — you keep deno fmt for the "just make it consistent" pass, and dprint fmt for the full fidelity pass when you need something exotic.

And since the maintainer asked above which option you're missing: that's actually the actionable path. Options get promoted into deno fmt when users make the case that they're (a) stable in dprint across versions, (b) meaningful enough to be ecosystem-wide, and (c) can't be handled by the standalone-dprint pattern. Naming the specific dprint option you needed in a reply here (or an issue) is how the supported set grows — "I wanted X and had to leave deno fmt to get it" is exactly the data that informs that line.