Implement the updated JS decorators proposal

[arackaf]

Suggestion

Implement Decorators!

🔍 Search Terms

TypeScript Decorators

List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.

Decorators

✅ Viability 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, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Not sure - this would be badly breaking against your legacy decorators feature, but I think it meets the goal to align TS with JS

⭐ Suggestion

The TypeScript proposal is now Stage 3!!!

https://github.com/tc39/proposal-decorators

We've all seen the issue from hell requesting better typing support for decorators

#4881

but now that the proposal is moving forward, currently at Stage 3, I thought I'd open this issue to see if there are plans to finally, fully implement (and type) the ES version of decorators.

📃 Motivating Example

N/A - just implementing new JS features, to keep JS and TS aligned.

💻 Use Cases

All the various ways decorators can be used.

[DanielRosenwasser]

I think the first step will be implementing decorators. We're not going to try to model the "decorators can change the types of things" portion at first, but I think we can get something good and working.

[arackaf]

Daniel Rosenwasser (@DanielRosenwasser) that sounds perfect.

But just to be clear, annotating how a decorator change’s a type will be on the roadmap long term?

[glen-84]

Shhh, don't say "long term". 😉

[wycats]

Daniel Rosenwasser (@DanielRosenwasser) the biggest "type-related" transformation that comes up for me in the current implementation of decorators is communicating that a field decorator initializes the field's value.

I think that this would just fall out of accessor decorators (since the decorator turns into a getter, the concept of an uninitialized value no longer makes sense). Is that right?

Also, a regular field decorator might still want to communicate that the value is initialized (for example, a decorator that implements a default by returning a new initializer). Is it possible to address the issue of communicating that a decorator initializes the value on a different timeframe than arbitrary type transformation, or is it just as hard?

[Jamesernator]

We're not going to try to model the "decorators can change the types of things" portion at first, but I think we can get something good and working.

Simple transform decorators should be easy enough to support right?

Like:

function wrapInBox<R>(f: () => R): () => { value: R } {
    return () => { value: f() };
}

class Foo {
    @wrapInBox
    method(): number {
        return 3;
    }
}

const foo = new Foo();
foo.method(); // should be { value: number }, same as regular function wrapping

Has very little difference to (type inference wise):

class Foo {
    method = wrapInBox((): number => {
        return 3;
    });
}

(Ignoring the prototype vs own property distinction here).

Isn't it primarily the metadata-based type-mutations that are hard to actually support? (given they need to communicate types across calls)

[trusktr]

Daniel Rosenwasser (@DanielRosenwasser) that sounds perfect.

But just to be clear, annotating how a decorator change’s a type will be on the roadmap long term?

Besides this, also picking types from a class by specific decorator would be wonderful... in the longer term. :D

[trusktr]

Also, a regular field decorator might still want to communicate that the value is initialized (for example, a decorator that implements a default by returning a new initializer). Is it possible to address the issue of communicating that a decorator initializes the value on a different timeframe than arbitrary type transformation, or is it just as hard?

Do you mean something like this?

class Foo {
  @alwaysString foo = 123 // initializes it to "123"
}

I think TypeScript would create the type right then and there, at class definition. The user cannot (write any code that will)
observe a moment when the value is a number instead of a string, apart from the decorators themselves.

Another thing could be that maybe decorators can augment the type of a class, but not necessarily the type of the thing they decorate directly. For example, this

class Foo {
  @withDouble count = 123
}

could add a new doubleCount variable that is always the double of count whenever count changes. The type would be { count: number, doubleCount: number } where count was not modified.

However, I think that with this new decorator API, decorator functions can be completely generic, with their input and output types completely known by TypeScript. So, this should be possible:

function alwaysString<T, C extends ...>(_: T, context: C): (initial: T) => string {
  if (context.kind !== 'field') return // type narrowing based on union of string values for `kind`

  return initial => initial.toString()
}

and based on something like this, I imagine it totally possible for TypeScript to look at the return type and determine that the final type of the property should always be a string (or to always have any setter, string getter).

But a version with class types not modifiable would still be totally usable!

[ruojianll]

I suggest implement decorators first, then add type support. The current legacy class decorator could return a non-class constructor value, and it won't be recognized by ts type system, but it is still easy to use.

Or we just use legacy version until stage 4 published, but maybe they are waiting us to do something to verify their design in stage 3.

[wycats]

I suggest implement decorators first, then add type support

As long as @dec accessor foo understands that you don't need to explicitly initialize foo, I think I can live with that.