Allow decorated accessor properties to have a different type

[NullVoxPopuli]

🔍 Search Terms

I was pretty sure an issue already existed for this, but I couldn't find it. Hopefully opening a new issue (to maybe be closed again) will improve SEO.

Here is what I searched for:

• decorators change type
• decorators accessor type
• decorators change type accessor

I did find this related issue:

• Refine type checking for class accessor when using decorator  #52559

✅ Viability Checklist

• 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, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Allow decorator's return type, ClassAccessorDecoratorResult to specify a different Value-type than what is on the right-hand side of the equals.

Here is how TS 5.6.3 handles this situation today.

📃 Motivating Example

For example, it should be possible to author this with 0 errors:

class Demo {
  @unwrap accessor num = { wrapped: 2 };
  //               ^? => number

  get usage() {
    expectTypeOf(this.num).toEqualTypeOf<number>();
  }
}

💻 Use Cases

1. Reactivity
2. Hiding complex behaviors from the user
3. Unwrapping private objects into public API (the example in the playground link)

[shigma]

A related issue for method decorators: #49229

[lilnasy]

I ran into this while attempting to type decorator example at proposal-signals/signal-polyfill/README.md#decorators.

relevant code excerpt

import { Signal } from "signal-polyfill";

export function signal(target) {
  const { get } = target;

  return {
    get() {
      return get.call(this).get();
    },

    set(value) {
      get.call(this).set(value);
    },

    init(value) {
      return new Signal.State(value);
    },
  };
}

The limitation seems to be that typescript assumes the publicly exposed value will have the same type as the value stored on the private accessor storage. The code example is a counter-example to that assumption: the type of the internal value is Signal.State<PublicValue> instead.

More specifically, the interfaces ClassAccessorDecoratorTarget, and ClassAccessorDecoratorResult are limited:

• ClassAccessorDecoratorTarget needs to allow the second generic argument to be unrelated to the public value type. This is because it reads from and writes to the accessor storage, not the public instance.
• ClassAccessorDecoratorResult needs to allow the return value type of .init() to be unrelated to the return value type of .get() and the paramter value type of .set(). This is because .init() relates to the value on the accessor storage, not the public value.