Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to deprecate a single parameter #131

Open
JoshuaKGoldberg opened this issue Nov 9, 2018 · 4 comments
Open

How to deprecate a single parameter #131

JoshuaKGoldberg opened this issue Nov 9, 2018 · 4 comments
Labels
general discussion Not a bug or enhancement, just a discussion

Comments

@JoshuaKGoldberg
Copy link
Contributor

palantir/tslint#4281 is an example of a scenario where a single parameter is deprecated: moving from multiple standalone arguments to a single arguments object, while maintaining backwards compatibility.

Can we mark just that parameter as deprecated? Something like:

export interface IFormatter {
    /**
     * Formats linter results
     * @param failures - Linter failures that were not fixed
     * @param @deprecated fixes - Fixed linter failures. Available when the `--fix` argument is used on the command line. 
     */
    format(failures: RuleFailure[], fixes?: RuleFailure[]): string;
}
@octogonz
Copy link
Collaborator

octogonz commented Nov 9, 2018

Hmm... I find it odd to deprecate only part of an API signature. Would this be a better approach?

export interface IFormatter {
    /**
     * Formats linter results
     * @param failures - Linter failures that were not fixed
     */
    format(failures: RuleFailure[]): string;

    /**
     * @deprecated Use {@link IFormatter.(format:1)} instead.
     */
    format(failures: RuleFailure[], fixes?: RuleFailure[]): string;
}

This way the new contract and deprecated contract are each clearly described.

Also it follows our standard convention that @deprecated should always include a recommendation of what to use instead.

@octogonz octogonz added the general discussion Not a bug or enhancement, just a discussion label Nov 9, 2018
@JoshuaKGoldberg
Copy link
Contributor Author

That's a great suggestion, thanks @pgonzal! I can't think of a situation off the top of my head in which this wouldn't be doable, but will try.

@snebjorn
Copy link

snebjorn commented Feb 17, 2021

I've noticed an issue. @deprecated will affect the overloads.

In the below func(a) is also marked as @deprecated

interface Foo {
  /** @deprecated */
  func(a, b);
  func(a);
}

This can easily be fixed by inserting some TSDoc on func(a)

interface Foo {
  /** @deprecated */
  func(a, b);
  /** fixes being marked as deprecated  */
  func(a);
}

But this trick doesn't work on functions outside of interfaces/classes

/** @deprecated */
function func(a, b);
/** new stuff */
function func(a) {}

image

@lloydjatkinson
Copy link

This would be greatly helpful for union types.

export type FormatName =
    | 'date-month-year-and-twelve-hour-time-with-period'
    | 'date-year-month-date'
    | 'month-name-with-day-number'
    | 'month-name-with-ordinal-date'
    /**
     * @experimental
     */
    | 'relative'
    | 'twelve-hour-time-with-period'
    | 'twelve-hour-time'
    | 'twenty-four-hour-time';

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
general discussion Not a bug or enhancement, just a discussion
Projects
None yet
Development

No branches or pull requests

4 participants