2.0.0-beta.2

[MichalLytek]

Features

• Breaking Change: AuthChecker type is now "function or class" - update to AuthCheckerFn if the function form is needed in the code
• Breaking Change: update graphql-js peer dependency to ^16.6.0
• Breaking Change: buildSchemaSync is now also checking the generated schema for errors
• Breaking Change: validate option of buildSchema is set to false by default - integration with class-validator has to be turned on explicitly
• Breaking Change: validate option of buildSchema doesn't accept anymore a custom validation function - use validateFn option instead
• support class-based auth checker, which allows for dependency injection
• allow defining directives for interface types and theirs fields, with inheritance for object types fields (Add directives support to Interfaces #744)
• allow deprecating input fields and args (Allow deprecating input fields and arguments #794)
• support disabling inferring default values (Allow disabling inferring the default values from properties initializers #793)
• support readonly arrays for roles of @Authorized decorator (Support readonly arrays for roles of Authorized decorator #935)
• add sync version of buildTypeDefsAndResolvers function (Update buildTypeDefsAndResolvers.ts #803)
• lift restriction of listing all interfaces from inheritance chain in implements option of @ObjectType decorator (Use Date scalars from graphql-scalars instead of custom ones #1435)

Fixes

• Breaking Change: properly emit types nullability when defaultValue is provided and remove ConflictingDefaultWithNullableError error (Inconsistent behavior for defaultValue and nullable on input types #751)
• allow defining extension on field resolver level for fields also defined as a property of the class (Using @Extensions and Object Inheritance problem #776)
• fix throwing error when schema with dynamic default value was built again (Rebuilding schema results in failure due to default value analysis #787)
• fix converting inputs with fields of nested array type (Failure while deserializing an input type with a nested array field #801)
• disable broken exposing input types fields under a changed name via @Field({ name: "..." })
• support overwriting fields of extended types (Overriding properties in subclass for InputType does not work correctly. #1109)
• properly execute args validation for nullable items array (Validation fails if query arg is a list with null items #1328)

Others

• Breaking Change: update class-validator peer dependency to >=0.14.0
• Breaking Change: change build config to ES2019 - drop support for Node.js < 14.5
• Breaking Change: remove support for loading resolvers by glob paths (resolvers: string[] build schema option)
• Breaking Change: remove isAbstract legacy decorator option

---

This discussion was created from the release 2.0.0-beta.2.

[MichalLytek]

Please report here all the issues encountered using this beta release 😉

[AChangXD]

Thanks Michal!

[hlspablo]

Awesome Michal

[chrisbruford]

Is there any documentation around the removal of isAbstract? the above notes it's "legacy" but I can still find numerous instances of it being the recommended approach?

https://prisma.typegraphql.com/docs/basics/usage/
https://typegraphql.com/docs/generic-types.html#basic-usage

[MichalLytek]

If you check the latest docs:
https://typegraphql.com/docs/next/generic-types.html#basic-usage
The isAbstract is removed from the code snippets.

isAbstract was related to the "build all from storage" approach before 1.0 release and have no impact when you not used string path-based resolvers option while building schema.

[fliitor]

[MichalLytek]

Missing args means it's an issue with your custom compiler - next.js, babel, swc, esbuild, tsx, etc.

[MichalLytek]

How the hell

@Arg("record", of => `${TItemClass.name}InputUpdate`)

was working for you? You can't put string names of the types, but JS class references.

[bnussman]

2.0.0-beta.2 has been working solid in production for https://github.com/bnussman/beep! 🎉

[thongxuan]

we are still find isAbstract useful when you want to multiple decorators on a single field, for example

//-- in one file
@ObjectType({isAbstract: true})
@inputType()
class Item {
}

class Collection {
@field({nullable: true})
items?: Item[];
}

//-- in other files
import {Item as ItemBase} from "./one";

@ObjectType()
export class Item extends ItemBase {
@directive('some_directive')
some_other_field: SomeOtherClass;
}

[MichalLytek]

There should be no changes between having isAbstract and not. In v1.x releases isAbstract was ignored for resolvers: [Foo, Bar].