feat: Deprecate formatting rules

[nzakas]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[x] Other, please explain:

Deprecates rules

What changes did you make? (Give an overview)

Deprecates the agreed-upon rules

Fixes #17522

Is there anything you'd like reviewers to focus on?

Please double-check that I didn't miss any of the rules we agreed to deprecate.

[netlify]

✅ Deploy Preview for docs-eslint canceled.

Name	Link
🔨 Latest commit	b0f87f8
🔍 Latest deploy log	https://app.netlify.com/sites/docs-eslint/deploys/65450a1c0a14e60007d85748

[nzakas]

Deprecated rules are automatically removed from eslint:all.

[nzakas]

No idea why I'm getting a warning around marking rules as deprecated. It seems like I've set up everything correctly.

[mdjermanovic]

No idea why I'm getting a warning around marking rules as deprecated. It seems like I've set up everything correctly.

We should update the docs too.

Example:

eslint/docs/src/rules/no-return-await.md

Line 10 in c0b11dd

This rule was **deprecated** in ESLint v8.46.0 with no replacement. The original intent of this rule no longer applies due to the fact JavaScript now handles native `Promises` differently. It can now be slower to remove `await` rather than keeping it. More technical information can be found in [this V8 blog entry](https://v8.dev/blog/fast-async).

[antfu]

I wonder if there would be a better phrase than "deprecated with no replacement" (as we http://eslint.style/ are taking over as the "replacement") - maybe point to the blog post instead?

[nzakas]

@mdjermanovic the output seems to indicate that either updating the source code OR updating the README should satisfy this check. However, from the code, it looks like both are required. I'll fix the messaging as part of this.

@antfu We can do that. Is the prefix for all rules @stylistic/js? And is the URL format always https://eslint.style/rules/js/<ruleId>?

[antfu]

Yes, exactly. Thanks

[mdjermanovic]

This test will fail when we release @eslint/js v8.53.0 because semi and func-call-spacing are no longer in eslint:all, so it might be good to update it now:

eslint/tests/lib/eslint/eslint.js

Lines 481 to 508 in 485ec7d

	it("should use eslint:all rules when eslint:all configuration is specified", async () => {
	eslint = new ESLint({
	useEslintrc: false,
	overrideConfig: {
	extends: ["eslint:all"]
	},
	ignore: false,
	cwd: getFixturePath()
	});
	const options = { filePath: "file.js" };
	const results = await eslint.lintText("foo ()", options);
	assert.strictEqual(results.length, 1);
	const { messages } = results[0];
	// Some rules that should report errors in the given code. Not all, as we don't want to update this test when we add new rules.
	const expectedRules = ["no-undef", "semi", "func-call-spacing"];
	expectedRules.forEach(ruleId => {
	const messageFromRule = messages.find(message => message.ruleId === ruleId);
	assert.ok(
	typeof messageFromRule === "object" && messageFromRule !== null, // LintMessage object
	`Expected a message from rule '${ruleId}'`
	);
	assert.strictEqual(messageFromRule.severity, 2);
	});

[mdjermanovic]

no-extra-semi and no-mixed-spaces-and-tabs are also in the recommended config. Since they're deprecated, perhaps we should remove them from the recommended config as well?

eslint/packages/js/src/configs/eslint-recommended.js

Line 37 in 485ec7d

"no-extra-semi": "error",

eslint/lib/rules/no-extra-semi.js

Line 26 in 485ec7d

recommended: true,

eslint/packages/js/src/configs/eslint-recommended.js

Line 47 in 485ec7d

"no-mixed-spaces-and-tabs": "error",

eslint/lib/rules/no-mixed-spaces-and-tabs.js

Line 18 in 485ec7d

recommended: true,

[nzakas]

I fixed the test. We generally don't remove rules from eslint:recommended outside of a major release. It's one thing to deprecate rules, but I don't think people will expect rules that they have enabled via eslint:recommended to be turned off in a minor release. Maybe we wait and do that in v9.0.0?

[mdjermanovic]

I fixed the test.

Did you push that change?

[nzakas]

Oops. 😆 Got distracted. Pushed now.

[mdjermanovic]

We generally don't remove rules from eslint:recommended outside of a major release. It's one thing to deprecate rules, but I don't think people will expect rules that they have enabled via eslint:recommended to be turned off in a minor release. Maybe we wait and do that in v9.0.0?

I agree with removing those two rules from eslint:recommended in v9.0.0.

Our semver policies do allow removing rules from eslint:recommended in a minor version, but I think we used that clause only when some rules had problematic behavior.

[nzakas]

Our semver policies do allow removing rules from eslint:recommended in a minor version, but I think we used that clause only when some rules had problematic behavior.

Yes, that was the intent. 👍 I added a note to remove these rules in v9.0.0: #17596

[mdjermanovic]

LGTM, thanks!

[siarheipashkevich]

@nzakas how to see all deprecated rules which are used in my project running CLI command?