feat: support additional metadata for rule deprecations

[bmish]

Summary

This RFC suggests a format for storing additional information in rule metadata about rule deprecations and replacement rules, allowing automated documentation and website tooling to generate more informative deprecation notices.

Related Issues

• https://github.com/eslint/eslint/issues/18061

[aladdin-add]

@bmish there are a few more comments here. :)

[mdjermanovic]

@bmish just to check, are you still working on this?

[nzakas]

@bmish Just checking in. Are you still working on this?

[nzakas]

@bmish there are some outstanding comments to address. Are you still interested in finishing this RFC?

[bmish]

I'd like to finish it up but it might be a while until I find some time.

[nzakas]

@bmish can you give us a rough timeframe so we can know when to follow up?

[nzakas]

@bmish it's been a month since the last ping. Do you have a timeframe for when you plan on finishing this up?

[nzakas]

Hi everyone - we're looking for someone who's interested in this RFC to pick it up and push it over the finish line. If you're interested, please leave a comment here.

[DMartens]

I'm interested in finishing this. I'm in favor of only using the deprecated key as there is a strict relationship between deprecated and replacedBy and checking whether the legacy form is used is simple: if (rule.meta.deprecated || "replacedBy" in rule.meta). With that and the notes from others it would like this:

type RuleMeta = {
	deprecated?: {
		replacedBy?: ...
		plugin?: string | { name?: string, url?: string } // Question: Should it be required that the name is its id on npm? or allow other registries such as jsr. Also worth documenting is if it should be set if it is from the same plugin
		rule?: string | { name?: string, url?: string }
		info?: string | { message?: string, url?: string } // Originally "meta"

		// Additions
		deprecatedSince?: string // Version string since when the rule is deprecated
		availableUntil?: null | string // Version or date when the rule will be removed or null if the rule is frozen
	}
}

Another thing worth mentioning is we could get rid of requiring one property (either url or name) in the object forms if the shorthand string should be interpreted smartly: if it starts with a protocol (e.g. https:// it is shorthand for the url and otherwise for message or name. Then the object forms would require both properties to be set.

[nzakas]

@DMartens I'd say put all of those thoughts into the RFC and we can go from there.

[fasttime]

@DMartens Thanks for picking up the work on this RFC. Feel free to open a new pull request as you probably don't have write access to the source repo here.

[nzakas]

@DMartens are you still interested in picking this up?

[DMartens]

Sorry, I wanted to proofread it the next day and forgot. Anyways the proposal is continued in #124.

[nzakas]

No worries. We'll close this and continue the discussion on #124.