refactor: depracate decorators with GraphQL prefix

Author: MichalLytek

CHANGELOG.md

@@ -5,6 +5,7 @@
 - add base support for GraphQL enums using TypeScript enums
 - add support for defining GraphQL unions
 - add support for importing resolvers from file path glob
+- depracate decorators with `GraphQL` prefix - use `@ArgsType`, `@InputType`, `@InterfaceType`, `@ObjectType` and `@Resolver` instead
 ### Fixes
 - fix not working array type notation in circular dependencies (correct thunk generation)
 

README.md

@@ -22,7 +22,7 @@ We have API for cooking recipes and we love using GraphQL for it.
 At first we will create the `Recipe` type, which is the foundations of our API:
 
 ```ts
-@GraphQLObjectType()
+@ObjectType()
 class Recipe {
   @Field(type => ID)
   readonly id: string;
@@ -42,7 +42,7 @@ class Recipe {
 ```
 Take a look at the decorators:
 
-- `@GraphQLObjectType()` marks the class as the object shape known from GraphQL SDL as `type`
+- `@ObjectType()` marks the class as the object shape known from GraphQL SDL as `type`
 - `@Field()` marks the property as the object's field - it is also used to collect type metadata from TypeScript reflection system
 - the parameter function in decorator `@Field(type => ID)` is used to declare the GraphQL scalar type like the builit-in `ID`
 - due to reflection limitation, optional (nullable) fields has to be annotated with `{ nullable: true }` decorator param
@@ -62,7 +62,7 @@ type Recipe {
 Next, we need to define what is the `Rate` type:
 
 ```ts
-@GraphQLObjectType()
+@ObjectType()
 class Rate {
   @Field(type => Int)
   value: number;
@@ -82,16 +82,16 @@ So, as we have the base of our recipe related types, let's create a resolver!
 
 We will start by creating a class with apropiate decorator:
 ```ts
-@GraphQLResolver(objectType => Recipe)
+@Resolver(objectType => Recipe)
 export class RecipeResolver {
   // we will implement this later
 }
 ```
-`@GraphQLResolver` marks our class as a resolver of type `Recipe` (type info is needed for attaching field resolver to correct type).
+`@Resolver` marks our class as a resolver of type `Recipe` (type info is needed for attaching field resolver to correct type).
 
 Now let's create our first query:
 ```ts
-@GraphQLResolver(objectType => Recipe)
+@Resolver(objectType => Recipe)
 export class RecipeResolver {
   constructor(
     // declare to inject instance of our repository
@@ -110,7 +110,7 @@ export class RecipeResolver {
 
 So, how the `FindRecipeArgs` looks like?
 ```ts
-@GraphQLArgsType()
+@ArgsType()
 class FindRecipeArgs {
   @Field(type => ID)
   recipeId: string;
@@ -167,7 +167,7 @@ class RecipeResolver {
 
 Here's how `RateInput` type looks:
 ```ts
-@GraphQLInputType()
+@InputType()
 class RateInput {
   @Field(type => ID)
   recipeId: string;
@@ -176,7 +176,7 @@ class RateInput {
   value: number;
 }
 ```
-`@GraphQLInputType()` marks the class as the `input` in SDL, in oposite to `type` or `scalar`
+`@InputType()` marks the class as the `input` in SDL, in oposite to `type` or `scalar`
 
 The corresponding GraphQL schema:
 ```graphql
@@ -209,7 +209,7 @@ class RecipeResolver {
 
 The whole `RecipeResolver` we discussed above with sample implementation of methods looks like this:
 ```ts
-@GraphQLResolver(objectType => Recipe)
+@Resolver(objectType => Recipe)
 export class RecipeResolver {
   constructor(
     // inject the repository (or other services)
@@ -269,7 +269,7 @@ So the GQL type classes would be also reused by ORM or validation lib:
 import { Entity, ObjectIdColumn, Column, OneToMany, CreateDateColumn } from "typeorm";
 
 @Entity()
-@GraphQLObjectType()
+@ObjectType()
 export class Recipe {
   @ObjectIdColumn()
   @Field(type => ID)
@@ -300,7 +300,7 @@ export class Recipe {
 ```ts
 import { IsMongoId, Min, Max } from "class-validator";
 
-@GraphQLInputType()
+@InputType()
 class RateInput {
   @IsMongoId()
   @Field(type => ID)

docs/authorization.md

@@ -9,7 +9,7 @@ And that's why authorization is a first-class feature in `TypeGraphQL`!
 At first, you need to use `@Authorized` decorator as a guard on a field or a query/mutation.
 Example object type's fields guards:
 ```ts
-@GraphQLObjectType()
+@ObjectType()
 class MyObject {
   @Field()
   publicField: string;
@@ -34,7 +34,7 @@ This way authed users (regardless of theirs roles) could read only `publicField`
 
 Sample query and mutations guards:
 ```ts
-@GraphQLResolver()
+@Resolver()
 class MyResolver {
   @Query()
   publicQuery(): MyObject {

docs/dependency-injection.md

@@ -27,7 +27,7 @@ Then, your resolvers will be able to declare their dependecies and TypeGraphQL w
 import { Service } from "typedi";
 
 @Service()
-@GraphQLResolver(objectType => Recipe)
+@Resolver(objectType => Recipe)
 export class RecipeResolver {
   constructor(
     // constructor injection of a service

docs/enums.md

@@ -36,7 +36,7 @@ registerEnum(Direction, {
 
 The last step is very important: TypeScript has limited reflection ability, so we have to explicitly provide the enum type both for object/input type fields as well as return type of queries/mutations or arg type:
 ```ts
-@GraphQLInputType()
+@InputType()
 class JourneyInput {
   @Field(type => Direction) // it's very important
   direction: Direction;

docs/interfaces-and-inheritance.md

@@ -9,10 +9,10 @@ TypeScript has first class support for interfaces. Unfortunatelly, they exist on
 
 Luckily, we can use abstract class for this purpose - it behave almost like an interface (can't be "newed", can be implemented by class), it just won't stop developers from implementing a method or initializing a field. But until we do the same things like with an interface, we can safely use it.
 
-So, how to create GraphQL interface definition? We create an abstract class and decorate it with `@GraphQLInterfaceType()`. The rest is exactly the same as with object types - we use `@Field` to declare the shape of the type:
+So, how to create GraphQL interface definition? We create an abstract class and decorate it with `@InterfaceType()`. The rest is exactly the same as with object types - we use `@Field` to declare the shape of the type:
 
 ```ts
-@GraphQLInterfaceType()
+@InterfaceType()
 abstract class IPerson {
   @Field(type => ID)
   id: string;
@@ -28,7 +28,7 @@ abstract class IPerson {
 Then we can use this "interface" in object type class definition:
 
 ```ts
-@GraphQLObjectType({ implements: IPerson })
+@ObjectType({ implements: IPerson })
 class Person implements IPerson {
   id: string;
   name: string;
@@ -47,7 +47,7 @@ One of the most known principles of software development is DRY - don't repeat y
 
 While creating GraphQL API, it's a common pattern to have pagination args in resolvers, like `skip` and `take`. So instead of repeating yourself, you can declare it once: 
 ```ts
-@GraphQLArgsType()
+@ArgsType()
 class PaginationArgs {
   @Field(type => Int, { nullable: true })
   skip: number = 0;
@@ -59,7 +59,7 @@ class PaginationArgs {
 
 and then reuse it everywhere:
 ```ts
-@GraphQLArgsType()
+@ArgsType()
 class GetTodosArgs extends PaginationArgs {
   @Field({ nullable: false })
   onlyCompleted: boolean = false;
@@ -69,7 +69,7 @@ class GetTodosArgs extends PaginationArgs {
 This technique also works with input type classes, as well as with object type classes:
 ```ts
 // `Person` is the object type class we've created earlier in this docs
-@GraphQLObjectType()
+@ObjectType()
 class Student extends Person {
   @Field()
   universityName: string;

docs/scalars.md

@@ -11,7 +11,7 @@ This shorthand allows you to save keystrokes when declaring field type:
 // import the aliases
 import { ID, Float, Int } from "type-graphql";
 
-@GraphQLObjectType()
+@ObjectType()
 class SampleObject {
   @Field(type => ID)
   readonly id: string;
@@ -27,7 +27,7 @@ In the last case you can ommit the `type => Float` since JavaScript `Number` wil
 
 Other scalars - `GraphQLString` and `GraphQLBoolean` doesn't need aliases - when it's possible, they will be reflected automatically:
 ```ts
-@GraphQLObjectType()
+@ObjectType()
 class User {
   @Field()
   name: string;
@@ -39,7 +39,7 @@ class User {
 
 However in some cases you will have to explicitly declare the string/bool scalar type. Use JS constructor functions (`String`, `Boolean`) then:
 ```ts
-@GraphQLObjectType()
+@ObjectType()
 class SampleObject {
   @Field(type => String, { nullable: true })
   get optionalInfo(): string | undefined { // TS reflected type is `Object` :(
@@ -69,7 +69,7 @@ const schema = await buildSchema({
 
 There's no need to explicitly declare the field type then:
 ```ts
-@GraphQLObjectType()
+@ObjectType()
 class User {
   @Field()
   registrationDate: Date;
@@ -108,7 +108,7 @@ Then you can just use it in your field decorators:
 // import the earlier created const
 import { ObjectIdScalar } from "../my-scalars/ObjectId";
 
-@GraphQLObjectType()
+@ObjectType()
 class User {
   @Field(type => ObjectIdScalar) // and explicitly use it
   readonly id: ObjectId;
@@ -123,7 +123,7 @@ class User {
 
 Optionally, you can delcare the association between reflected property type and your scalars to automatically map them (no need to explicit type annotation!):
 ```ts
-@GraphQLObjectType()
+@ObjectType()
 class User {
   @Field() // magic goes here - no type annotation for custom scalar
   readonly id: ObjectId;

docs/unions.md

@@ -7,7 +7,7 @@ You can read more about GraphQL union type in [official docs](http://graphql.org
 Let's start by creating the object types from example above:
 
 ```ts
-@GraphQLObjectType()
+@ObjectType()
 class Movie {
   @Field()
   name: string;
@@ -17,7 +17,7 @@ class Movie {
 }
 ```
 ```ts
-@GraphQLObjectType()
+@ObjectType()
 class Actor {
   @Field()
   name: string;
@@ -41,7 +41,7 @@ All that left to do is to use the union type in the query.
 Notice, that due to TypeScript's reflection limitation, you have to explicitly use `SearchResultUnion` value in `@Query` decorator return type annotation.
 For TS compile-time type safety you can also use `typeof SearchResultUnion` which is equal to type `Movie | Actor`.
 ```ts
-@GraphQLResolver()
+@Resolver()
 class SearchResolver {
   @Query(returnType => [SearchResultUnion])
   async search(

docs/validation.md

@@ -8,7 +8,7 @@ And that's why TypeGraphQL has bulit-in support for validation of arguments and
 ## How to use
 At first, you have to decorate the input/arguments class with appropiate decorators from `class-validator`. So we take this:
 ```ts
-@GraphQLInputType()
+@InputType()
 export class RecipeInput {
   @Field()
   title: string;
@@ -21,7 +21,7 @@ and produce this:
 ```ts
 import { MaxLength, Length } from "class-validator";
 
-@GraphQLInputType()
+@InputType()
 export class RecipeInput {
   @Field()
   @MaxLength(30)
@@ -36,7 +36,7 @@ And that's it! :wink:
 
 TypeGraphQL will automatically validate your inputs and arguments based on the definitions:
 ```ts
-@GraphQLResolver(objectType => Recipe)
+@Resolver(objectType => Recipe)
 export class RecipeResolver {
   @Mutation(() => Recipe)
   async addRecipe(@Arg("input") recipeInput: RecipeInput): Promise<Recipe> {

examples/authorization/index.ts

@@ -3,14 +3,14 @@ import * as express from "express";
 import * as graphqlHTTP from "express-graphql";
 import { buildSchema } from "../../src";
 
-import { Resolver } from "./resolver";
+import { ExampleResolver } from "./resolver";
 import { Context } from "./context.interface";
 import { authChecker } from "./auth-checker";
 
 void async function bootstrap() {
   // build TypeGraphQL executable schema
   const schema = await buildSchema({
-    resolvers: [Resolver],
+    resolvers: [ExampleResolver],
     authChecker, // register auth checking function
   });