Please add scope parameter to disable formatting for current workspace

[MrZyr0]

Hi,

Thank you for your extension. I use it all the time to switch between personal and professional projects.

In this case, it might be nice to have an option to have the extension turn off formatting only for the workspace or folder scope.

For example, in my work, projects use only Eslint on the command line for formatting, which works fine. In my personal projects, I have all the tools configured: Eslint, Prettier, Stylelint... that I don't want to disable manually one by one and depending on the projects.

Another example, in some cases you want to disable formatting just because it creates multiple diffs on a file, but you don't want to disable formatting across all your vscode windows for that!

[Tom-Bonnike]

You’re not the first person to request that (https://github.com/Tom-Bonnike/vscode-formatting-toggle/issues/58) but I struggle to understand a proper use-case for toggling workspace settings: 1) they are usually tracked on Git as they are meant to be shared with other people; allowing to quickly toggle these settings might make people stage/commit them when they didn’t mean to. 2) toggling formatting when working on a specific file is probably not the right solution? There are configurations like .prettierignore you can use to ignore formatting on a specific file, and all formatting-related settings should be the same across all files in a project? If not, the proper solution would be to re-format the whole project first IMO?

---

Either way, since people seem to be asking for it, here is what the VS Code Extension API allows:

A value can be changed in

• Global settings: Changes the value for all instances of the editor.
• Workspace settings: Changes the value for current workspace, if available.
• Workspace folder settings: Changes the value for settings from one of the Workspace Folders under which the requested resource belongs to.

[…]

Parameter	Description
configurationTarget?: ConfigurationTarget | boolean | null	The configuration target or a boolean value. - If true updates Global settings. - If false updates Workspace settings. - If undefined or null updates to Workspace folder settings if configuration is resource specific, otherwise to Workspace settings.

Currently, the extension always updates the Global configuration. I would be happy to make this behaviour configurable if you confirm that this would solve your problem.

I would probably only allow boolean | null and default the option to true. What do you think?

[felipecrs]

For everyone subscribed to this issue, the microsoft/vscode#135706 is now a candidate to VSCode's backlog. If you would like it to be implemented, please cast your vote with a thumbs up 👍 on it (20 are required).

It explains a way to allow this extension to override the workspace configuration without changing the .vscode/settings.json file of it.

[MrZyr0]

Hi 👋

Thank you for your quick reply, and sorry for my late reply.

Here is a use case: I have fully configured prettier and eslint on my new projects and on my vscode editor. I did this because I want to format all my personal projects using these rules.

But, I also use the same computer and vscode configuration for my work where prettier is not configured, and they don't want to use it. Also, eslint is used for fomatting but with a different configuration. Eslint is applied automatically because of a specific configuration on save, so automatic formatting is not useful.

Worse than that, it should not be enabled! If I keep formatting on, and I edit a file, it will be automatically formatted. This makes sense, but I don't want to do it because it means I'll commit a lot of changes when I'm only editing a small number of lines…

Is this more consistent for you?

---

I think that you perpose can be interesting, since a specified false or null value in .vscode/settings.json or in Workspace setting automatically disable formating.

By default, it could be true.

[markbiek]

Another vote for being able to turn formatting off for some workspaces while enabling it for others.

[Tom-Bonnike]

If you have workspace settings, then you are sharing that configuration with other people. If you want to ignore formatting for a specific file, this extension is IMO not the right tool for the job. You should add a .prettierignore to your project, or update your ESLint configuration.

I would like to understand why that isn’t a good solution?

[markbiek]

First off, let me just say THANK YOU! This extension is super useful and free. Also, I super appreciate your responsiveness and willingness to discuss all this.

I'm in the same situation as @MrZyr0 . I have some saved workspaces that I want to disable formatting on and others that I don't. It would be nice to open a saved workspace and have it remember if formatting is turned on/off for that specific workspace.

I'm thinking that it's similar to how I can enable and disable VSCode extensions on a per-workspace basis.

If you have workspace settings, then you are sharing that configuration with other people.

I'm not really sure what you mean by this? Maybe we're talking about different things?

When I say workspace, I'm talking about a saved workspace file that exists on my computer for a specific project.

For example:

{
        "folders": [
                {
                        "path": "../dev/a8c/calypso"
                }
        ],
        "settings": {
                "workbench.colorCustomizations": {
                        "sash.hoverBorder": "#93e6fc",
                        "statusBar.background": "#61dafb",
                        "statusBar.foreground": "#15202b",
                        "statusBarItem.hoverBackground": "#2fcefa",
                        "statusBarItem.remoteBackground": "#61dafb",
                        "statusBarItem.remoteForeground": "#15202b",
                        "titleBar.activeBackground": "#61dafb",
                        "titleBar.activeForeground": "#15202b",
                        "titleBar.inactiveBackground": "#61dafb99",
                        "titleBar.inactiveForeground": "#15202b99",
                        "commandCenter.border": "#15202b99"
                },
                "peacock.color": "#61dafb"
        }
}

The above file isn't shared with anyone. It only lives on my computer and I'm the only one who uses it.

[Tom-Bonnike]

The VS Code workspace settings are meant to be committed to git along with your project’s code, so that they are shared with all other contributors of the project that are also using VS Code. It overrides your user settings. It’s useful to enforce that every contributor always has editor.codeActionsOnSave and editor.formatOnSave enabled, for example, no matter their own personal VS Code settings. (This is the root of this issue!)

If this extension were to override these formatting workspace settings, it would have to update that file (on disk), causing you to risk committing the setting update for everybody. It’s not the biggest issue, you can always pay attention and not commit it or revert the change, but what I’m arguing for is that even if this extension allowed you to update the workspaces settings, it would only be a temporary fix. (I didn’t realize people were using VS Code workspace settings without committing them, tbh. 😅)

If you don’t want formatting on a specific file, other contributors most likely don’t want it either! This is why I’m suggesting updating your .prettierignore or ESLint settings to ignore specific files. You can also disable the formatting for specific languages this way e.g.:

{
  "[ruby]": {
    "editor.formatOnSave": false
  }
}

In your case, if the workspace settings are not shared, why not simply remove the formatting settings from your workspace settings? Then they won’t override your personal settings, and the extension will work as expected.

[markbiek]

The VS Code workspace settings are meant to be committed to git along with your project’s code, so that they are shared with all other contributors of the project that are also using VS Code. It overrides your user settings. It’s useful to enforce that every contributor always has editor.codeActionsOnSave and editor.formatOnSave enabled, for example, no matter their own personal VS Code settings. (This is the root of this issue!)

Understood, that makes sense 🙏 .

If this extension were to override these formatting workspace settings, it would have to update that file (on disk), causing you to risk committing the setting update for everybody. It’s not the biggest issue, you can always pay attention and not commit it or revert the change, but what I’m arguing for is that even if this extension allowed you to update the workspaces settings, it would only be a temporary fix. (I didn’t realize people were using VS Code workspace settings without committing them, tbh. 😅)

This also makes sense and is definitely a good argument in favor of not making this change. I'll be honest that I've never used workspace settings in the way you're describing. Funny that we have opposite strategies here! 😆

If you don’t want formatting on a specific file, other contributors most likely don’t want it either! This is why I’m suggesting updating your .prettierignore or ESLint settings to ignore specific files. You can also disable the formatting for specific languages this way e.g.:

{
  "[ruby]": {
    "editor.formatOnSave": false
  }
}

I haven't need this functionality yet but I'm glad to know it's possible.

In your case, if the workspace settings are not shared, why not simply remove the formatting settings from your workspace settings? Then they won’t override your personal settings, and the extension will work as expected.

I think this is the answer. Right now, I'm doing everything formatting with global settings which doesn't seem like the best way to handle it.

Anyway, thanks again!

[markbiek]

@Tom-Bonnike I did have one more thought.

We've been talking about the workspace settings (.vscode/settings.json).

Is it possible that the formatting enabled/disabled status could be saved to the .workspace file instead (similar to how the Peacock extension does it)?

[Tom-Bonnike]

What's a .workspace file? I can’t find any mentions of it in the VS Code documentation nor in Peacock’s 🤔 Is it an alias for .vscode/settings.json?

[markbiek]

A .workspace file is basically a file collection of paths to folders and it can also have settings. Opening the .workspace file opens VSCode with all of those folders.

Those settings are separate from the settings in .vscode/settings.json.

More details: https://code.visualstudio.com/docs/editor/workspaces

You can create one with the Save Workspace menu:

Simple one would look like this:

{
        "folders": [
                {
                        "path": "~/dev/experiments/golang"
                }
        ],
        "settings": {
                "peacock.color": "#61dafb"
        }
}

And this is what I get when I open that workspace in VSCode:

You can see in the workspace settings that I have a peacock color defined. This tells the Peacock extension to change the border of the main VSCode window to the specified color, but only for this particular workspace. I have a .workspace file for every project I work on regularly.

I don't know anything about extensions and how they work. But it'd be cool if the formatting extension had a setting that you could put in the .workspace file that determined if formatting was enabled or disabled just for that workspace.

[Tom-Bonnike]

it'd be cool if the formatting extension had a setting that you could put in the .workspace file that determined if formatting was enabled or disabled just for that workspace.

Can't you already do that by putting formatting-related settings in there?

[markbiek]

Can't you already do that by putting formatting-related settings in there?

Hmm 🤔 . I guess that should work. I'll have to give it a try.

[markbiek]

Yup, that does the trick. I put the following in the .workspace file and disabled the formatting toggle extension as well.

"editor.formatOnPaste": false,
"editor.formatOnType": true,
"editor.formatOnSave": false

[Tom-Bonnike]

I’m pretty sure a scope parameter is an anti-pattern, so I’ll (finally) close this 👀 I left a note about workspace settings in the README.