dprint / dprint-vscode

Visual Studio Code extension for formatting code with dprint.

dprint

Monorepo for dprint—a pluggable and configurable code formatting platform.

Links

• Overview
• Getting Started
• Playground

Plugins

• dprint-plugin-typescript - TypeScript/JavaScript code formatter.
• dprint-plugin-json - JSON/JSONC code formatter.
• dprint-plugin-markdown - Markdown code formatter.
• dprint-plugin-toml - TOML code formatter.
• dprint-plugin-jupyter - Jupyter notebook code block formatter.
• dprint-plugin-dockerfile - Dockerfile code formatter.
• dprint-plugin-biome - Biome (JS/TS) wrapper plugin.
• dprint-plugin-prettier - Prettier wrapper plugin.
• dprint-plugin-roslyn - Roslyn (C#/VB) wrapper plugin.
• dprint-plugin-ruff - Ruff (Python) wrapper plugin.
• dprint-plugin-exec - Formats code with any CLI executable.

Notes

This repo is under active early development.

1. The interface between the CLI and plugins might change often. You may need to keep updating to the latest version of both the CLI and plugins (the CLI will let you know what to do).
   • An upgrade path will be outlined in the release notes when this occurs.
2. I do a lot of this development in my spare time. Please consider sponsoring if you are a commercial company using this.

dprint-vscode's Issues

Error text encoding problem.

see the screenshot,
not error itself, but the text.

Support for dprint installed locally with yarn

Currently there seems to be the workaround of "dprint.path" to indicate the path inside local node_modules. But given that modern Yarn doesn't have a node_modules folder, how could one fix this?

For reference, this page mentions how the editor SDK hooks up with Prettier. It would be great to have something like this with dprint :)

Extension does not load when opening a workspace where dprint.json is in a parent directory

We have a monorepo where dprint.json is at the root level, but we have a workspace set up that only has a subset of the folders loaded. For example:

/
  dprint.json
  backend/
  some-service/
  web/ <-- vscode is opened with this folder
     src/
       foo.tsx

Removing the activationEvents clause in the package.json fixes this for us. The editor service is happy to format it since it will just traverse for the dprint.json on disk where it is actually present, and if it isn't, then there's an error for that already anyway.

Allow getting dprint path from a command.

I should be able to do something like

  "dprint.path": "$(yarn bin dprint)",

or even better

  "dprint.command": "yarn run dprint",

That way if the extension wants to run check it would just do dprint.command check

Update for new editor service

See dprint/dprint#284

should have default global dprint when there is not dprint config file under workspace

In real company project, maybe other don't want to use dprint as default format plugin, most people use prettier, if this extension can have setting to control global settings for dprint we could use dprint extension in such scenario

The path of "includes" should be relative from dprint.json

The folder structure is as follows.

project_root/  <-- Open this folder in vscode
  foo/
    dprint.json
    src/
      index.js

dprint.json is follows.

{
  "typescript": {
  },
  "includes": ["src/**/*.{ts,tsx,js,jsx,cjs,mjs,json}"],
  "excludes": [
    "**/node_modules"
  ],
  "plugins": [
    "https://plugins.dprint.dev/typescript-0.88.3.wasm",
    "https://plugins.dprint.dev/json-0.15.0.wasm"
  ]
}

I want to format the index.js file.

Using CLI, following command formats index.js as expected.

cd project_root/foo
dprint fmt

Using VSCode extension, Shift + Alt + F command does not format index.js.

I tried to change includes path to the relative path from the folder opened in vscode.

  "includes": ["foo/src/**/*.{ts,tsx,js,jsx,cjs,mjs,json}"],

This works.

I think that relative path should be based on location of dprint.json.

`Dockerfile` not formatted from extension

The Format Document VSCode command (ie Shift + Alt + F) does not format dockerfiles.
dprint fmt works as expected.

.vscode/settings.json:

  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll": true,
  },
  "[json][javascript][javascriptreact][typescript][typescriptreact][markdown][dockerfile]": {
    "editor.defaultFormatter": "dprint.dprint"
  }

dprint.json:

{
  "includes": [
    "**/dockerfile"
  ],
  "plugins": [
    "https://plugins.dprint.dev/dockerfile-0.3.0.wasm"
  ]
}

Dockerfile (the extra lines should be removed):

FROM node:16 AS builder



COPY . .

dprint.dprint: v0.13.3

0.13.2 fails to format

A few hours ago I noticed VSC/dprint had stopped formatting files, and if the VSC window was unfocused, it'd just show an infinite progress bar for dprint in the lower corner. I hadn't noticed that VSC had installed an extension update, until I went and investigated a little.

I've rolled the dprint plugin back to 0.13.1 for now and it works again. Might need to check the code committed for 0.13.2? Happy to help debug if I can. This is on a Mac running MacOS 12.5.

dprint isn't found in "${workspaceFolder}/node_modules/dprint/dprint"

I am installing dprint using npm, but the extension fails to find it by specifying dprint.path to be "${workspaceFolder}/node_modules/dprint/dprint" on Windows. It works if I specify the full path.

rg/ripgrep when searching for config file causes excessive CPU usage on startup

I have a vscode workspace that includes several very large monorepos and noticed my CPU usage would be pegged to 100% for 30s-1m when loading my workspace after I installed this extension. Disabling this extension made the problem go away but I figured it wasn't actually dprint causing the problem since I know from experience it's very efficient

I took a quick recording showing me reloading the window and the subsequent CPU spike:

cpu.mov

And here is the culprit command:

/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar.unpacked/@vscode/ripgrep/bin/rg --files --hidden --case-sensitive -g /*/**/{dprint,.dprint,.dprintrc}.json -g !**/.git -g !**/.svn -g !**/.hg -g !**/CVS -g !**/.DS_Store -g !**/Thumbs.db --no-ignore --follow --no-config --no-ignore-global

Which led me to the glob used to find the dprint config file

dprint-vscode/src/constants.ts

Line 1 in 902df44

export const DPRINT_CONFIG_FILENAME_GLOB = "{dprint,.dprint,.dprintrc}.json";

And some particularly suspect usages

dprint-vscode/src/WorkspaceService.ts

Lines 68 to 87 in 902df44

	async initializeFolders(): Promise<FolderInfos> {
	this.#assertNotDisposed();
	this.#clearFolders();
	if (vscode.workspace.workspaceFolders == null) {
	return [];
	}
	for (const folder of vscode.workspace.workspaceFolders) {
	this.#folders.push(
	new FolderService({
	workspaceFolder: folder,
	configUri: undefined,
	outputChannel: this.#outputChannel,
	}),
	);
	// now search within sub directories to find any configuration files
	const subConfigFiles = await vscode.workspace.findFiles(`*/**/${DPRINT_CONFIG_FILENAME_GLOB}`);
	for (const subConfigFile of subConfigFiles) {

---

The first thing that comes to mind is also ignoring node_modules but that n^2 search seems unnecessary or could be made better with some short circuit checks.

I'd be happy to implement a fix or at least some short circuit paths since all my workspace folders contain a dprint.json file. I just want to check first to see if there are any recommendations before I dive further into the codebase.

Only works in first Workspace

Given a VSCode Workspace
and a configuration like the below,

dprint-vscode fails to format on save any other package than the first one.

An error is briefly displayed in the status bar.

Changing the order of folders in the workspace config (e.g. moving packageC to position one) will result in that we can now format on save packageC but not the other ones.

{
  "folders": [
    {
      "path": "packageA"
    },
    {
      "path": "packageB"
    },
    {
      "path": "packageC"
    }
  ],
  "settings": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "dprint.dprint"
  }
}

Option (and default) to prefer project-local dprint executable when available

dprint can now be installed as an npm dependency. I would love that VSCode will use the version locally installed with the current project when possible. One benefit is that a team can ensure the same version is being used.

Should only format files matched by .dprintrc.json

Right now it formats any files that match a supported extension. This is wrong and it shouldn't match any files not specified in the configuration file.

~ in dprint.path is no longer expanded

Previously specifying a path relative to home, e.g. ~/bin/dprint, for dprint.path worked.

Since #34, the ~ is no longer expanded, as bash does not expand ~ in double quotes.

Support vscode web extension mode

A distinct advantage of dprints wasm plugin approach is that it should be possible to perform all formatting operations without a real extension host, i.e. in the browser.

Reference: VS Code Web Extensions

This would enable formatting operations in the github.dev in-browser editing experience, which is extremely valuable.

dprint doesn't want to format `jsonc` (JSON with Comments) files

Here's a quick repro using .vscode/settings.json:

{
  "files.associations": {
    "*.json": "json",
    "extensions.json": "jsonc",
    "settings.json": "jsonc",
    ".eslintrc*.json": "jsonc",
    "dprint*.json": "jsonc",
    "tsconfig*.json": "jsonc"
  },
  "[json][jsonc][javascript][javascriptreact][typescript][typescriptreact][markdown][dockerfile]": {
    "editor.defaultFormatter": "dprint.dprint"
  }
}

dprint.dprint: v0.13.3

don't focus outputChannel on errors

When having network issues or if working offline, it is impossible to use VS Code with the dprint extension installed. The extension tries to download plugins several times and each time it fails, it focuses the output panel. So if someone tries to code or type something into the terminal, the focus gets lost and you can't really use VS Code for about 2 minutes until the extension does not perform retries anymore.

I can see that opening the output panel in case of an error makes sense, but it should do that only the first time. Focusing it every second is really annoying.

Config glob becomes forkbomb, creates infinite processes

There are cyclic symlinks in my setup and one of these lines(or all 3) are causing the extension to create infinite number of processes, the only escape being is to force shutdown the computer. So essentially, a forkbomb:

dprint-vscode/src/WorkspaceService.ts

Line 86 in 3379068

const subConfigFiles = await vscode.workspace.findFiles(`*/**/${DPRINT_CONFIG_FILENAME_GLOB}`);

dprint-vscode/src/extension.ts

Line 40 in 3379068

const fileSystemWatcher = vscode.workspace.createFileSystemWatcher(`**/${DPRINT_CONFIG_FILENAME_GLOB}`);

dprint-vscode/src/logger.ts

Line 41 in 3379068

const result = await vscode.workspace.findFiles("**/{dprint,.dprint,.dprintrc}.json");

I've fixed it locally by removing all the ** globs and let it just use the dprint.json at the top level of the workspace, I think this should be the default behavior unless someone needs to do something else? What do you think? So a configuration for the configGlob defaulting to just {dprint,.dprint,.dprintrc}.json. I didn't bisect it to see which one is the actual cause as the experience of having to turn off the computer every time isn't pleasant, but it's obvious to me that these are problematic and need to be configured.

Lazily initialize sub configurations

The extension should lazily initialize sub configurations until a format occurs.

Configure default formatter for TypeScript React

On 0.33.0 with 0.13.5, I'm trying to setup formatting on-save and got this when running format document by hand from the command palette:

workspace settings.json

{
    "editor.defaultFormatter": "dprint.dprint",
    "editor.formatOnSave": true,
    "editor.trimAutoWhitespace": true,
    "eslint.format.enable": false,
    "eslint.trace.server": "messages",
    "[javascript]": {
        "editor.defaultFormatter": "dprint.dprint",
        "editor.formatOnSave": true
    },
    "[javascriptreact]": {
        "editor.defaultFormatter": "dprint.dprint",
        "editor.formatOnSave": true
    },
    "[typescript]": {
        "editor.defaultFormatter": "dprint.dprint",
        "editor.formatOnSave": true
    },
    "[typescriptreact]": {
        "editor.defaultFormatter": "dprint.dprint",
        "editor.formatOnSave": true
    },
    "dprint.verbose": true
}

I disabled formatting for JS and TS in user settings.json. It seems to format json:

dprint.json

{
    "indentWidth": 4,
    "useTabs": false,
    "typescript": {
        "lineWidth": 120,
        "quoteStyle": "preferSingle",
        "jsx.quoteStyle": "preferDouble",
        "quoteProps": "asNeeded"
    },
    "includes": ["**/*.{ts,tsx,js,jsx,cjs,mjs}", "**/*.{json}"],
    "excludes": [
        "**/node_modules",
        "packages/",
        "__tests__/fixtures/*.json",
        "__mocks__/*.json",
        "**/*.fixture.json",
        "**/*.fixtures.json"
    ],
    "plugins": [
        "https://plugins.dprint.dev/typescript-0.78.0.wasm",
        "https://plugins.dprint.dev/json-0.16.0.wasm"
    ]
}

Feature request: Add an option to configure a custom location for .dprint.json

dprint supports a --config CLI parameter allowing for a custom configuration path to be specified. However, the VSCode plugin expects .dprint.json to be in the root of the workspace. It would be great if a configuration property could be added to the plugin, for example, "dprint.configurationFile": "path/to/my/dprint.json".

Bug: v0.15.1 stopped working

Thanks for the great formatter and plugin!

I'm facing an issue with the latest version; it seems to stop autoformatting,
also I can't find dprint command in command prompt to format. I rolled back to
v0.15.0, which works fine. Any tips for debugging the problem so I can provide
more information? Thanks!

don't show error message on syntax error

I find the message that appears on the bottom right slightly annoying:

I would rather dprint just not format when there is a syntax error. I think an option to toggle showing the error messages would be great.

VSCode extension cannot find dprint on PATH (it is there)

Not sure what's wrong. The messages says to ensure that dprint is globally installed, but it is already.

Rename Dprint: Reset to Dprint: Restart

JSON schema not being updated with plugin version changes

Today I bumped the TypeScript plugin to version 0.76.0, but when setting the jsx.bracketPosition setting (which is being added in this version) in my dprint.json file, I didn't get any JSON completions. The version in the plugin array is 0.76.0 and I can see the new setting being applied, so this seems like a schema issue.

The logs show that the extension is reading some cached files in Library/Caches/dprint/cache, and when I checked those out I noticed that the plugin version was still 0.75.0. I tried removing the cache manifest but it didn't fix the issue.

Maybe I'm just too eager to try the new setting lol because I can also see that the docs haven't been updated yet.

fails to format when config file in sub folder and has a relative includes glob

Using dprint extension v0.13.5
With vs code insiders:

Version: 1.75.0-insider (Universal)
Commit: e2816fe719a4026ffa1ee0189dc89bdfdbafb164
Date: 2023-02-01T15:16:42.458Z (3 hrs ago)
Electron: 19.1.9
Chromium: 102.0.5005.194
Node.js: 16.14.2
V8: 10.2.154.23-electron.0
OS: Darwin arm64 21.6.0
Sandboxed: Yes

For some reason, the dprint extension fails with this error:

Extension 'Dprint Code Formatter' is
configured as formatter but it cannot
format 'TypeScript'-files

Should update local state automatically when config file changes

This should handle when a config file changes.

Publish to Open VSX?

Publish to https://open-vsx.org/ ?

Add "target" and "associations" to json config schema provider

As title. We should add these CLI plugin properties.

Support "dprint" task in deno.json

If someone has something like the following in a deno.json/deno.jsonc file:

{
  "tasks": {
    "dprint": "deno run -A npm:[email protected]"
  }
}

...then maybe this dprint extension should understand that and use it for the dprint executable.

Hide syntax error messages after timeout

But how? I don't see any way in the vscode api to do a showErrorMessage with a timeout.

Support multiple config files in different directories

I think this doesn't work exactly right at the moment.

Support command to format any file with a default global configuration

See dprint/dprint#355

JSON schema not updated when config file shown when extension starts or after making updates to config file

Dynamic JSON schema was implemented in 4da3751

...however, it doesn't seem to update after changes are made or after making updates to the config file. I feel like I'm doing everything correctly though...

Add tests for opening a descendant directory of a folder with a config file

To prevent a regression for this: #49

Ignore searching the target folder in rust projects

[INFO] Initialized dprint 0.35.3
  Folder: v:\console_static_text\
  Command: dprint
[INFO] Initialized dprint 0.35.3
  Folder: v:\console_static_text\target\package\console_static_text-0.7.1\
  Command: dprint
[INFO] Initialized dprint 0.35.3
  Folder: v:\console_static_text\target\package\console_static_text-0.8.0\
  Command: dprint
[INFO] Initialized dprint 0.35.3
  Folder: v:\console_static_text\target\package\console_static_text-0.3.4\
  Command: dprint
[INFO] Initialized dprint 0.35.3
  Folder: v:\console_static_text\target\package\console_static_text-0.3.2\
  Command: dprint
[INFO] Initialized dprint 0.35.3
  Folder: v:\console_static_text\target\package\console_static_text-0.3.1\
  Command: dprint
[INFO] Initialized dprint 0.35.3
  Folder: v:\console_static_text\target\package\console_static_text-0.3.0\
  Command: dprint
[INFO] Initialized dprint 0.35.3
  Folder: v:\console_static_text\target\package\console_static_text-0.6.0\
  Command: dprint
[INFO] Initialized dprint 0.35.3
  Folder: v:\console_static_text\target\package\console_static_text-0.5.0\
  Command: dprint
[INFO] Extension active!

Investigate getting plugin schemas from "plugins" array

I wonder if there's a way to programatically specify the schema for a file with vscode instead of it being specified like "$schema": "https://dprint.dev/schemas/v0.json".

If so, then I could read all the plugins in the plugins array, get their schema urls, and generate a schema on the fly based on that.

Looks like there is this, but it won't work for what's necessary here... need a programmatic API:

https://code.visualstudio.com/api/references/contribution-points#contributes.jsonValidation

Specify cli bin path

I am having issues with vscode + deno + dprint. It says it cannot find dprint in vscode notifications, but in my zsh terminal dprint init and dprint work fine :/

And yes, I do have dprint in my path in my .zshrc configuration file, and that's why my terminal works fine. It just doesn't work when using vscode.
a possible solution would be to have a configuration option for the dprint vscode plugin to set the binary path.

dprint.experimentalLsp prevents config schema from being loaded

If you set "dprint.experimentalLsp": true and open a dprint config file, VS Code says:

Unable to load schema from 'dprint://schemas/config.json': cannot open dprint://schemas/config.json. Detail: Unable to resolve resource dprint://schemas/config.json.

Disable LSP and reload, and the error goes away.

It looks like the schema provider is a part of the legacy system, and probably just needs to be moved out. https://github.com/dprint/dprint-vscode/blob/main/src/legacy/context.ts#L22

🙏🏻 [feat/req] Allow specification of configuration file from VSCode config

It would be great to be able to specify a non-default configuration file to be used by the dprint formatter for a given workspace.

dprint-ignore comments ignored by vscode plugin but honoured when running the dprint cli directly

I have the following block of code that I'd like to remain formatted as is.
Running dprint fmt via the command line respects the comment & leaves the array as is.

However when I format the file via VsCode I get this.

My config below.

Running v0.45.0 of the dprint CLI.
Running v0.16.0 of the dprint.dprint plugin.

dprint.json

{
  "incremental": true,
  "lineWidth": 80,
  "newLineKind": "lf",
  "useTabs": false,
  "json": {},
  "toml": {},
  "typescript": {
    "deno": true,
    "ignoreFileCommentText": "dprint-ignore-file",
    "ignoreNodeCommentText": "dprint-ignore",
    "module.sortImportDeclarations": "caseInsensitive",
    "module.sortExportDeclarations": "caseInsensitive",
    "importDeclaration.preferSingleLine": true,
    "exportDeclaration.preferSingleLine": true
  },
  "markdown": {
    "textWrap": "always"
  },
  "dockerfile": {},
  "prettier": {
    "associations": [
      "**/*.{yml,yaml}"
    ]
  },
  "exec": {
    "commands": [
      {
        "command": "./.pixi/env/bin/shfmt",
        "exts": [
          "sh"
        ]
      }
    ]
  },
  "includes": [
    "**/*.{json,md,dockerfile,yml,yaml,toml,sh,ts}"
  ],
  "excludes": [
    "**/.pixi",
    "pixi.lock"
  ],
  "plugins": [
    "https://plugins.dprint.dev/toml-0.5.4.wasm",
    "https://plugins.dprint.dev/json-0.19.1.wasm",
    "https://plugins.dprint.dev/markdown-0.16.3.wasm",
    "https://plugins.dprint.dev/dockerfile-0.3.0.wasm",
    "https://plugins.dprint.dev/typescript-0.88.7.wasm",
    "https://plugins.dprint.dev/exec-0.4.4.json@c207bf9b9a4ee1f0ecb75c594f774924baf62e8e53a2ce9d873816a408cecbf7",
    "https://plugins.dprint.dev/prettier-0.32.0.json@fa93f05ab38f00c6de138f7747372585c661f79dfb11d7f1209c069b56680820"
  ]
}

.vscode/settings.json

{
  "deno.enable": true,
  "deno.cacheOnSave": true,
  "editor.defaultFormatter": "dprint.dprint",
  "editor.formatOnPaste": true,
  "editor.formatOnSave": true,
}

Format selection does not consider dprint a valid formatter

Hi, just started exploring dprint and tried this extension, formatting the document works fine but when I try to format a selection VScode complains about dprint not being a valid formatter for [current file type].

I could not understand if this was a limitation with the extension(/dprint) or a bug?

Minimal repro:

• Create a new folder
• Init dprint with default settings
• add newlines at top of dprint.json
• > Format document works as exepcted
• highlighting the newlines and selecting > Format selection (cmd+k cmd+f) throws in VScode with error:

"Extension 'Dprint Code Formatter' is configured as formatter but it cannot format 'JSON'-files"

My setup:
dprint: 0.37.1 (homebrew install)
VScode: 1.79.0
dprint.dprint extension: v0.14.0

Update instructions for more languages

As title.

Dprint task fails via VSCode extension on some large files

Here's the extension Output

[VERBOSE] Checking can format: /Users/stephaneledorze/Documents/projects/rebaze/nx-incubator/libs/filiburg/src/contexts/application.ts
[VERBOSE] Creating instance of dprint-plugin-typescript
[VERBOSE] Created instance of dprint-plugin-typescript in 0ms
[ERROR] Read task failed: Error: Expected success bytes, but found: [99, 111, 109, 101]
[ERROR] Error formatting text. Error: dprint's process exited while the message was in progress.

If I try to format in the repo via yarn dprint fmt or if I try yarn dprint check they work perfectly

I've tried to reproduce using the initial default config file generated by dprint init and it behaves the same

I've failed to shrink the repro as it appears that the problem is not specifically link to a specific part of a file
I can share the file privately however

Publish extension via tag

Would be easy to do and I should do it.

Log when no configuration file found

Say something about how no formatting will take place because no configuration file was found (obviously when there's support for a global config, it will format with the global config).

Give instructional error message when dprint cli is not installed

As title.

Support local node_modules installation in folders with spaces

It'd be great if the extension could pick up a local installation of dprint in node_modules (basically ./node_modules/.bin/dprint). That way, projects relying on package.json could declare the minimum version they need in the devDependencies property and people cloning the repository would not have to figure out how to do a global installation.