Decorators: @mutation, @query and @subscription

[AngelEVargas]

Adding decorators to indicate the kind of GraphQL operation.

@query
op read(): string;

@mutation
op update(): string;

@subscription
op get_periodically(): string

[steverice]

You could also use the builtin validateDecoratorNotOnType, e.g. have the @query decorator validate that the @mutation decorator and the @subscription decorator are not also applied.

I'm trying to think why that might be preferable. Perhaps there could be a scenario where the state is set but the other decorators aren't applied and we want to allow that.
I haven't tried this, but maybe something like

interface Get<T extends {}> {
  @get foo(): T[] | Error;
}

interface Widgets extends Get<Widget> {
  @post foo(...Widget): void
}

interface WidgetsAgain extends Get<Widget> {
  @put foo(...Widget): Widget;
}

would exercise a case where there is a difference between checking the state and checking the decorators. For instance, the HTTP verb decorators look for other decorators, even though the state handling is very similar:

typespec/packages/http/src/decorators.ts

Lines 424 to 429 in 3085652

	const verbDecorators = type.decorators.filter(
	(x) =>
	VERB_DECORATORS.includes(x.decorator) &&
	x.node?.kind === SyntaxKind.DecoratorExpression &&
	x.node?.parent === type.node,
	);

What I would do is look in the existing code for similar behavior.

[steverice]

Are you using eslint/prettier as defined in the TypeSpec repo? We should be sure to follow the same style rules as upstream.

[steverice]

Can we make this change first in a (very small) separate commit?

[steverice]

Do we need these types? We don't seem to be using them anywhere, and I don't see other emitters declaring types for all their decorators.

Indeed, from a type level, type MutationDecorator, type QueryDecorator, and type SubscriptionDecorator are all identical.