Skip to content

Preserve property comment and insert @default value, if provided #41486

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

Open
5 tasks done
jednano opened this issue Nov 11, 2020 · 4 comments
Open
5 tasks done

Preserve property comment and insert @default value, if provided #41486

jednano opened this issue Nov 11, 2020 · 4 comments
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript

Comments

@jednano
Copy link
Contributor

jednano commented Nov 11, 2020

Search Terms

default initial initializer value preserve comment tsdoc type options option bag

Suggestion

As the title suggests, insert a @default comment to the TSDoc AST if an initializer is provided, preserving the original comment.

Use Cases

I have a default value for an option and I want the consumer of the library to know what the default value is.

Examples

interface Options {
  /**
   * The server host.
   */
  host?: string;
  port?: number;
}

function serve({ host = 'localhost', port }: Options) {
  return { host, port };
}

Playground

Hovering over host in the return statement shows the following in vscode:

Screen Shot 2020-11-10 at 6 39 31 PM

Not only is the TSDoc comment lost for this property, but it could furthermore be improved if @default "localhost" were added to it, seeing as that information is available in this context.

It should look like this:

Screen Shot 2020-11-10 at 6 49 35 PM

Much ❤️ for the TS team!

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.
@MartinJohns
Copy link
Contributor

I think this is a duplicate of #32392.

@jednano
Copy link
Contributor Author

jednano commented Nov 11, 2020

I think this is a duplicate of #32392.

It’s related, but not the same, because that issue says nothing about @default comments.

@RyanCavanaugh RyanCavanaugh added Suggestion An idea for TypeScript Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature labels Nov 11, 2020
@jednano
Copy link
Contributor Author

jednano commented Feb 26, 2021

@RyanCavanaugh I've provided a detailed example of the scenarios that are missing tooltip information below 👇🏻

interface FooOptions {
  /**
   * original bar
   * @default 'original' original
   */
  bar?: string;
  /**
   * original baz
   * @default 'original' original
   */
  baz?: string;
}

{
  function foo({ bar = 'original' } = {}) {
    return bar;
  }

  foo({
    /**
     * Actual Tooltip:
     *   (property) bar?: string | undefined
     * Expected Tooltip:
     *   (property) bar?: string | undefined
     *   _@default — 'original' original_
     */
    bar: 'x'
  });
}

{
  interface ExtendedFooOptions extends FooOptions {
    /**
     * extended bar
     * @default 'extended' extended
     */
    bar?: string;
  }

  function foo({
    /**
     * Actual Tooltip:
     *   var bar: string
     * Expected Tooltip:
     *   var bar: string
     *   extended bar
     *   _@default — 'overridden' extended_
     */
    bar = 'overridden',
    /**
     * Actual Tooltip:
     *   var baz: string
     * Expected Tooltip:
     *   var baz: string
     *   original baz
     *   _@default — 'overridden' original_
     */
    baz = 'overridden'
  }: ExtendedFooOptions = {}) {
    return [
      /**
       * Actual Tooltip:
       *   var bar: string
       * Expected Tooltip:
       *   var bar: string
       *   extended bar
       *   _@default — 'overridden' extended_
       */
      bar,
      /**
       * Actual Tooltip:
       *   var baz: string
       * Expected Tooltip:
       *   var baz: string
       *   original baz
       *   _@default — 'overridden' original_
       */
      baz
    ] as const;
  }

  foo({
    /**
     * Actual Tooltip:
     *   (property) ExtendedFooOptions.bar?: string | undefined
     *   extended bar
     *   @default — 'extended'
     * Expected Tooltip:
     *   var bar: string
     *   extended bar
     *   _@default — 'overridden' extended_
     */
    bar: 'x',
    /**
     * Actual Tooltip:
     *   var baz: string
     * Expected Tooltip:
     *   var baz: string
     *   original baz
     *   _@default — 'overridden' original_
     */
    baz: 'y'
  });
}

Playground

@Danielku15
Copy link

I would also have a strong interest in providing default values in my TSdocs (d.ts) shipped in my package. I have a wide range of options in my settings classes and want to let people know the default values (in the IDE, but also when generating my website with the API docs).

My Input:

class MySettings {
   /**
    * Description of optionA.
    */
   public optionA:string = 'default string';
   /**
    * Description of optionB.
    */
   public optionB:number = 1.2;
   /**
    * Description of optionC.
    */
   public optionC:MyEnum = MyEnum.Value; 
}

In my d.ts output I'd like to have something like:

declare class MySettings {
   /**
    * Description of optionA.
    * @default `'default string'`
    */
   public optionA:string;
   /**
    * Description of optionB.
    * @default `1.2`
    */
   public optionB:number;
   /**
    * Description of optionC.
    * @default `MyEnum.Value`
    */
   public optionC:MyEnum; 
}

Looking at the interest of and age of this issue, I fear it might never come as an official feature. So I'm wondering: Is there maybe a good way customize the produced output and inject such tags? e.g. via the typescript compiler API using transformers? Some hints on where to adapt/extend the compiler would be very helpful for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

4 participants