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>
Currently the typegen output is designed with the assumption that @nexus/schema will be available at node_modules/@nexus/schema. This assumes that either the project depends on @nexus/schema or that @nexus/schema has been hoisted. The former is fine but does not support being wrapped by another tool, while the latter is liable to result in module not found errors for hard-to-debug reasons (especially users who know little or nothing about the internals).
* fix: typegen stable path generation with Windows
When using Windows, rootTypings paths are using `\` instead of `/` in generated code. This commit fixes it.
* Replace all Windows path separators in rootTypings
Co-authored-by: Tim Griesser <tgriesser10@gmail.com>