Revert deprecate code actions on format

[probably-neb]

Closes #40334

This reverts the change made in #39983, and includes a replacement migration that will transform formatter settings values consisting of only code_action format steps into the previously deprecated code_actions_on_format in an attempt to restore the behavior to what it was before the migration that deprecated code_actions_on_format.

This PR will result in a modified order in the code_actions_on_format setting if it existed, however the decision was made to explicitly ignore this for now, as this PR is primarily targeting users who have already had the deprecation migration run, and no longer have the code_actions_on_format key

Release Notes:

• Fixed an issue with a settings migration that deprecated the code_actions_on_format setting. The code_actions_on_format setting has been un-deprecated, and affected users will have the bad migration rolled back with an updated migration

[ottob]

This unfortunately broke my setup. Using the config below with 208.5. I migrated to 208.4 and that worked as expected.

"format_on_save": "on",
"languages": {
    "TypeScript": {
      "code_actions_on_format": {
        "source.fixAll.eslint": true
      }
    },
    "TSX": {
      "code_actions_on_format": {
        "source.fixAll.eslint": true
      }
    }
  }

when I save a file it flashes the correct the format

import { useState, useEffect, useCallback, useMemo } from 'react'

but its then immediately replaced with

import { useState, useEffect, useCallback, useMemo } from "react";

from my .eslintrc.js

  rules: {
    'prettier/prettier': [
      'error',
      {
        singleQuote: true,
        semi: false,
        trailingComma: 'es5',
      },
    ],

[caseywebdev]

I'm seeing the same behavior as you with

"format_on_save": "off",
"languages": {
  "JavaScript": {
    "format_on_save": "on",
    "formatter": [{ "code_action": "source.fixAll.eslint" }]
  }
},

It looks like within a fraction of a second the editor first correctly applies the desired formatting (that works in 208.4) and then immediately applying another layer of formatting from an unknown source, shifting it back to incorrect.

[ottob]

Seems like its tracked now in #40334

Heh, or maybe that was the source of the issue. Sorry.

[ottob]

Interesting, if I change my settings to

"languages": {
    "TypeScript": {
      "formatter": ["auto", { "code_action": "source.fixAll.eslint" }]
    },
    "TSX": {
      "formatter": ["auto", { "code_action": "source.fixAll.eslint" }]
    }
  }

then it first flashes the wrong formatting, and then corrects it with the proper one.

"languages": {
    "TypeScript": {
      "formatter": [{ "code_action": "source.fixAll.eslint" }]
    },
    "TSX": {
      "formatter": [{ "code_action": "source.fixAll.eslint" }]
    }
  }

and this setting will only give me the wrong formatting.

[foretoo]

0.208.5 broke formating, it doesn't use my eslint rules any more

[ottob]

I might have figured it out. I read on https://zed.dev/docs/languages/typescript#language-servers

Prettier will also be used for TypeScript files by default.

Maybe this is a new default?

So I guessed the auto above would have been the default prettier formatter that cause the flash of wrongly styled content.
If I change my setting to

"languages": {
    "TypeScript": {
      "prettier": { "allowed": false },
      "formatter": [{ "code_action": "source.fixAll.eslint" }]
    },
    "TSX": {
      "prettier": { "allowed": false },
      "formatter": [{ "code_action": "source.fixAll.eslint" }]
    }
  }

It now works as expected. No flashes of wrongly formatted content. Though it prompts for a migrations. The following also works:

"languages": {
    "TypeScript": {
      "code_actions_on_format": {
        "source.fixAll.eslint": true
      },
      "prettier": { "allowed": false }
    },
    "TSX": {
      "code_actions_on_format": {
        "source.fixAll.eslint": true
      },
      "prettier": { "allowed": false }
    }
  }

[yizixu]

I'm shocked that even the most basic ESLint formatting is failing. I've recommended Zed to so many friends, and encountering such issues is downright embarrassing.

[Vadim2308]

@yizixu I spent 3 days but still couldn't get Eslint+ Prettier to work on ZED. While I'm working on Webstorm, that's the only thing that really upsets me.

[foretoo]

@ottob thanks for your investigation, but for some reason "prettier": { "allowed": false } still allowes some prettier formatting, looks like some prettier rules still leak into formatting processes, that is so weird 😄 so i still have conflicts, but not all over the whole file, just in some parts of it

[yizixu]

我发现了一个有趣的方法

{
  "code_actions_on_format": {
    "source.fixAll.eslint": true
  },
  "prettier": {
    "allowed": false
  },
  "language_servers": ["eslint"],
}

但是对于vue的temelate需要两次保存才能生效

[nicolas-giuristante]

I'm sharing my project settings files that currently works (95% of the time...) in case it helps someone in the meantime.

It was not easy to figure out how to make it all work together and to be honest, it fails rarely but randomly at times; A restart of language servers or Zed is necessary.

I am not a dev, mostly a designer who codes with a decent knowledge about Laravel + Vue project structures in a monorepo. So I'm not entirely sure my settings make any sense. Does eslint lint my JSON files? I don't know, but at the moment it works.

I would appreciate to know if my settings are aligned with the current/desired settings structure or if it's legacy.

./.zed/settings.json

{
    "format_on_save": "on",
    "languages": {
        "JavaScript": {
            "language_servers": [
                "...",
                "eslint"
            ],
            "prettier": { "allowed": false },
            "formatter": [
                { "code_action": "source.fixAll.eslint" }
            ]
        },
        "JSON": {
            "language_servers": [
                "...",
                "eslint"
            ],
            "prettier": { "allowed": false },
            "formatter": [
                { "code_action": "source.fixAll.eslint" }
            ]
        },
        "JSONC": {
            "language_servers": [
                "...",
                "eslint"
            ],
            "prettier": { "allowed": false },
            "formatter": [
                { "code_action": "source.fixAll.eslint" }
            ]
        },
        "TSX": {
            "language_servers": [
                "...",
                "eslint"
            ],
            "prettier": { "allowed": false },
            "formatter": [
                { "code_action": "source.fixAll.eslint" }
            ]
        },
        "TypeScript": {
            "language_servers": [
                "...",
                "eslint"
            ],
            "prettier": { "allowed": false },
            "formatter": [
                { "code_action": "source.fixAll.eslint" }
            ]
        },
        "Vue.js": {
            "language_servers": [
                "...",
                "vue-language-server",
                "vtsls",
                "eslint"
            ],
            "prettier": { "allowed": false },
            "formatter": [
                { "code_action": "source.fixAll.eslint" }
            ]
        },
        "PHP": {
            "formatter": {
                "external": {
                    "command": "bash",
                    "arguments": [
                        "-c",
                        "cat > {buffer_path} && ./apps/main/vendor/bin/pint --quiet {buffer_path} && cat {buffer_path}"
                    ]
                }
            }
        }
    },
    // [...]
}

Remember to make sure no other conflicting settings are in your user settings. Even though, technically, the project settings are supposed to overwrite user settings.

[caseywebdev]

After futzing this is the simplest config I could get working for me on 0.208.6. I kind of assumed something like "formatter": null or "formatter": [] would disable the default formatter but no luck, this "hack" seems to do it though.

{
  "format_on_save": "off",
  "languages": {
    "JavaScript": {
      "format_on_save": "on",
      "code_actions_on_format": { "source.fixAll.eslint": true },
      // HACK: Disable default formatter
      "formatter": { "language_server": { "name": "" } }
    }
}

[probably-neb]

Hello all, my deepest apologies for breaking your formatting, and for leaving it broken for so long.

We are rolling out a fix in #40916, but unfortunately it will not fix the issue for those who have already updated and migrated. If you were already affected (as everyone who has commented thus far is) then placing "formatter": [] in your settings (once accepting the migration to change "formatter" to "code_actions_on_format") should fix the issue.

If doing so does not fix your issue, please please open a new issue describing what you are experiencing, and we will try to help you fix it as soon as possible

Explanation

The settings migration in this PR (which will happen in memory when we load your settings, we only migrate your settings file on disk after you click the "backup and migrate" button), made it so that "formatter" settings that only contained code actions e.g.

  "formatter": [
                { "code_action": "source.fixAll.eslint" }
            ]

Would be migrated to "code_actions_on_format": { "source.fixAll.eslint": true },

This was done to fix issues we encountered after attempting to deprecate the "code_actions_on_format" setting, by trying to effectively "undo" the faulty deprecation migration.

This however, resulted in the removal of the "formatter" key, causing it to then be inherited from the defaults (or the top level "formatter" value of your settings.json file if one was set). For JS/TS based languages, this is "auto", which we interpret as prettier, if it is enabled (which it is for JS/TS based languages), otherwise the default language server. End result: we'd end up running prettier even though your pre-migrated settings would prevent prettier from running.

We're planning to take a deeper look at how we can simplify, and improve these settings so that they are less confusing, and much harder to break like we did in this PR.