Decorator context.kind "object-getter" or "getter"

[Jack-Works]

type ObjectLiteralGetterDecoratorContext = {
  kind: "object-getter"; // or just "getter"?
  ... // other properties from ObjectLiteralMethodDecoratorContext
}

type ObjectLiteralSetterDecoratorContext = {
  kind: "object-setter"; // or just "setter"?
  ... // other properties from ObjectLiteralMethodDecoratorContext
}

I can think of a new option: add a new property in the context.

  kind: 'field'
  container: 'class' | 'object' // | 'enum' | 'protocol'

this allows us to extend in the future, for example, if we have enum or protocol as the syntatic container.

[Jamesernator]

Yes this is a lot simpler as it indicates what kind of thing metadata will installed on.

I would suggest having this even for root containers, so that the type in this proposal would be:

container: "class" | "object" | "function"

[rbuckton]

This was something I also explored in https://github.com/tc39/proposal-decorators/issues/466 and it's something I'd like to revisit.

Ideally, container would be more flexible than just a string:

type DecoratorContext = {
  ...
  container?: {
    kind: "class" | "struct" | "object" | "enum" | "protocol";
    name: string | undefined;
    addInitializer(initializer: () => void): void; // adds a static initializer
  };
};

I'd thought about having context.metadata only be available if the decorated element itself could have metadata (i.e., class, function), while you would use context.container.metadata if you were a child element (i.e., methods, getters, setters, fields, etc.). That would have allowed methods have access to both own metadata and container metadata, so a function decorator could be used on a method more readily.

However, I don't think we should go about changing context.metadata at stage 3, which is part of why the explainer includes a suggestion to use the name context.functionMetadata.