- Fixes SDL conversion
- Defer wrapping until types are built
- Supports GraphQL types anywhere that a type can be used, wrapped, etc.
- Split out the wrapping, w/ `finalizeWrapping` helper which adds in the `NonNull` to the list as needed
- Make `nonNull(nonNull(T))` & `nullable(nullable(T))` no-op for simplicity
- Change: `nullable(nonNull(T))` will undo the `nonNull`
- Properly type-check's `subscriptionType` by passing `Event` generic properly
- Adds `declarativeWrappingPlugin` for previous `nullable` / `list` behavior
Co-authored-by: Flavian DESVERNE <flavian.desverne@epitech.eu>
Co-authored-by: Tim Griesser <tgriesser10@gmail.com>
closes#632
BREAKING CHANGE:
SDL file generation will be enabled by default in development now.
If you were enabling it manually before and outputting to project root at `schema.graphql` You can probably now just rely on the default.
If you were relying on the default to disable SDL file generation before then now you need to pass an explicit false:
```ts
makeSchema({
outputs: {
schema: false
}
})
```
Adds `t.modify` API for modifying inherited types.
Use cases:
- If you have an `interface` type, but want to override the resolver or description for the field per-`objectType`
- If an inherited field's value is abstract, and you want to narrow it to a subtype which conforms to the inherited type
- If you want to add additional optional arguments for an inherited field, as is permitted by the spec
The types should validate that only fields inherited from interfaces can be modified, and the `type` can only be
changed if the result of that field is an abstract type which implements the existing inherited return type.
This PR removes the `nullable: boolean` and `list: boolean | boolean[]` API and replaces it with top-level type wrappers named: `list()`, `nonNull()` and `nullable()`
BREAKING CHANGES:
- `isTypeOf` is now the _default_ strategy to discriminate members of an abstract type. To keep using `resolveType` as you might have been before, enable the following config in `makeSchema`:
```ts
makeSchema({
features: {
abstractTypeStrategies: {
resolveType: true
}
}
})
```
closes#582
As discussed. In most cases resolver shorthands are not a serious use of the API.
BREAKING CHANGE:
Resolver shorthand API is now removed. The following will now not typecheck:
```ts
t.string('foo', () => ... )
```
Instead use:
```ts
t.string('foo', { resolve: () => ... })
```
Runtime support is still intact but will result in a logged warning. Runtime support will be removed in the next Nexus release.
Fixes#588 by ensuring that list items follow `nonNullDefaults`, which was lost in the #508 refactor
Fixes#384 by removing explicit nullability config from the connection `edges` definition, and also allowing `nonNullDefaults` to be supplied for the connection "types" generated by the creation of a connection field. Allows you to configure both globally in the connection plugin field config, and when the connection field is defined.
closes#581
BREAKING CHANGE:
`ext` is no longer exported. The `relayConnectionField` and `collectionField` dynamic output methods have been removed. In their place try the `connection` plugin.
fixes#402fixes#450
Fixes:
- Global connection field extensions were never executed
- Typings of global connection field extension (root, args and the resolver return type was wrong)
- Typings of local connection field extension (everything was any)
closes#410
BREAKING CHANGE:
The graphql peer dep requirement has been bumped to v15.
No graphql v15 exclusive features have been shipped yet. But this update
sets us up to begin that work.
Support for graphql v14 and lower has been dropped. It may technically work
still (the test suite did not show any major reasons why it won't, for
now/currently) but there is no guarantee about that remaining so in the
future. Internally we are only testing against v15. Certain new grpahqljs
v15 features like interfaces being able to implement other interfaces will
be released in the future.
If you absolutely cannot upgrade from graphql v14 right now then stay with
@nexus/schema v15. But if you also really need a new @nexus/schema feature
on v16+ (future) then you can try your luck with it an older version of
graphqljs.
Co-authored-by: Jason Kuhrt <jasonkuhrt@me.com>
- Create a new `NexusGenScalars` for all scalar types
- Remove scalars from `NexusGenRootTypes` (might be a breaking change, need review)
- Use the `NexusGenScalars` for all non specified (base GraphQL) scalars in `input` and `output` types
- Add `rootTyping` parameter to `asNexusMethod` to allow the user to specify it, otherwise it will fallback to the `backingTypeMap`
BREAKING CHANGE:
The global TS type `NexusGenRootTypes` no longer contains scalars. All scalars now live under a new global TS type named `NexusGenScalars`.
```ts
// before
let foo: NexusGenRootTypes['String']
```
```ts
// after
let foo: NexusGenScalars['String']
```
One internal type error was raised with 3.9 that wasn't before.
This might have led to end-users having to enable skipLibCheck?
For the uncertainty, treating this as a feature as opposed to a chore.
closes#392
BREAKING CHANGE:
Remember that internally Nexus Schema over-fetches by 1 but hides this internally.
It used to be that `SomeEdge.hasNextPage` would be `true` _if_ the number of returned nodes was greater-than OR equal-to the `first` arg value given in the query.
Now when Nexus Schema treats the `equal-to` case as `SomeEdge.hasNextPage` being `false`.
Co-authored-by: Eyal Wiener <eyalwiener@gmail.com>
Being able to build with type checking on but without typegen is not
inteded to be supported. The following workflows for example are:
1. --transpile-only development builds
2. IDE feedback based on types + typegen
3. production builds where no --transpile-only check is used, based on types + typegen
* feat(typegen): nicer generated package name
This can impact the end-user when they, for example, are using the `types` TS compiler option. In that situation, expressing a whitelist of TypeScript type-packages, in a Nexus app, it would be important that the user also include typegen or else tsc would stop seeing it (forcing the
user to do Nexus typegen config). To make it easier for users to do that, this change allows them refer to a pretty name, rather than something hard to predict, remember, and ugly looking.