🐛 Format the content of an in-memory editor in VS Code without configuration

[jsejcksn]

From biomejs/biome-vscode#25 (comment) — @ematipico asked me to create this here

Environment information

output of biome rage --daemon-logs

CLI:
  Version:                      1.4.1
  Color support:                true

Platform:
  CPU Architecture:             aarch64
  OS:                           macos

Environment:
  BIOME_LOG_DIR:                unset
  NO_COLOR:                     unset
  TERM:                         "xterm-256color"
  JS_RUNTIME_VERSION:           unset
  JS_RUNTIME_NAME:              unset
  NODE_PACKAGE_MANAGER:         unset

Biome Configuration:
  Status:                       unset

Workspace:
  Open Documents:               0

Discovering running Biome servers...

Server:
  Status:                       stopped

What happened?

It would be useful for Biome to be able to format the content of an editor which has never been saved (one which has no corresponding FS file). Here's an example:

1. Close all VS Code windows and quit the app. Open a fresh instance of VS Code with a blank window and no workspace. (Note that this step doesn't seem to alter the outcome.)
2. Open a new editor tab and paste in some copied source code text (e.g. TypeScript)
3. Verify that the language mode of the editor is correct for the pasted content (e.g. TypeScript) — in the case that it wasn't correctly auto-detected
4. Use the VS Code command "Format Document" from the command palette

Performing these steps results in an error modal with the following message:

Extension 'Biome' is configured as formatter but it cannot format 'TypeScript'-files

Expected result

However, it could accomplish this by treating the content the same way it does stdin and use the editor's current language mode to determine language.

In pseudo-code, the CLI operation that represents what I'm describing would be:

# FILE_EXT=<derived from editor language mode>
# e.g. ".ts"

# TEXT=<text content of editor>
# e.g. "function double(n: number): number { return n * 2 } const n = 5; double(5)"

printf $TEXT | biome format --stdin-file-path="file$FILE_EXT"

Which would result in:

function double(n: number): number {
	return n * 2;
}
const n = 5;
double(5);

Code of Conduct

• I agree to follow Biome's Code of Conduct

[ematipico]

I think I see the problem here. I think the Biome extension didn't start because you didn't trigger any of the events that start the extension.

That's why you couldn't see any logs

Try to open a JavaScript/JSX/TypeScript/JSON file, and then create a new file.

[jsejcksn]

Hi @ematipico:

Maybe this requires changing the strategic logic for extension activation? 🤷

Try to open a JavaScript/JSX/TypeScript/JSON file, and then create a new file.

I tried this approach in workspace with a biome.json configuration file at the root of the workspace and the result was no different. (Formatting works as expected for other text editors in the same workspace whose documents have filesystem representations.)

At this point it seems like there might be additional debugging in order — but first I want to clarify the expectations that prompted my initial comment:

When I set any VS Code extension as the default formatter for a language, I expect that it will be able to operate on the document content of any text editor that is in that language mode — whether that's associated with a workspace or not — whether or not there are any filesystem artifacts (like a config file), etc. The formatter functionality of such an extension should be independent of any of those variables and should be completely self-contained: it downloads any required binaries, allows default configuration via the VS Code extension settings, etc. If an extension supports custom behavior based on things like resolving configuration via files relative to a local (filesystem) workspace — those should be optional features, but not dependencies for operation.

I tried to illustrate this concept with the stdin example, but hopefully that description helps clarify where I'm coming from.

---

Aside: I've only been experimenting with Biome for a few days so far and haven't researched the roadmap, etc. — but it seems like this could be important in other scenarios, too — e.g. if Biome ever plans to offer a web extension.

[ematipico]

Biome ever plans to offer a web extension.

That's something I always wanted to have, and with WebAssembly we should achieve it. Hopefully someone will help us :)