Add DocumentNode to gql declaration #196
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
added
the
|
@kamilkisiela what was what I did on #193 😄 |
|
Thank you both! I don’t know much about Typescript, is this a breaking
change?
…On Wed, Jul 18, 2018 at 11:58 PM Yordis Prieto ***@***.***> wrote:
@kamilkisiela <https://github.com/kamilkisiela> what was what I did on
#193 <#193> 😄
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#196 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABERRiANl2awXxR8XVlHOY1XoemrL_VYks5uIC4GgaJpZM4VK1zf>
.
|
|
@jnwng no, this would actually help people to remove the |
|
It's not, |
|
btw @kamilkisiela @yordis i thought i had seen this before — this was previously introduced by #141 and subsequently had to be reverted because this is a breaking change (see #150) i'm not going to release this just yet — while im not afraid of cutting a major version here, i could use some help understanding why this a breaking change at all given that both of you mentioned that it isn't. any helpful information for TypeScript users here will help us head off unnecessary pain. |
jnwng
added a commit
that referenced
this pull request
Oct 2, 2018
This reverts commit ae792b6. Based on #196 and #150, introducing the `DocumentNode` return value causes this library to break for existing TypeScript installations. I'm reverting this temporarily so we can release support for GraphQL v14 in a minor patch, and if we can't fix the TypeScript configuration, we'll release a major version with this commit back in.
jnwng
added a commit
that referenced
this pull request
Oct 2, 2018
This reverts commit ae792b6. Based on #196 and #150, introducing the `DocumentNode` return value causes this library to break for existing TypeScript installations. I'm reverting this temporarily so we can release support for GraphQL v14 in a minor patch, and if we can't fix the TypeScript configuration, we'll release a major version with this commit back in.
hwillson
added a commit
that referenced
this pull request
Feb 4, 2020
This commit modernizes/fixes the existing TypeScript declaration file as follows: - The module declaration now better represents how exports are currently setup, by using module augmentation to give access to helper functions that are added to the `gql` function itself. - Backwards compatibility has been maintained by re-exporting helper functions. - Stronger typing changes; the first param of the `gql` template literal is now a read only string based array, and the `gql` return type is a `DocumentNode`. We're leveraging TS' [import types](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-9.html#import-types) functionality to reference the `DocumentNode` type, which will help avoid issues like the previously reverted attempts to do this in #151 and #196. - While the new `gql` type changes could in theory be considered breaking, they really shouldn't be in practice. Tagged template literals enforce the use of an immutable array of strings, which means that even though `literals` was `any` before, the param should only ever been an array of strings. Along the same lines, the `gql` function has only ever returned a `DocumentNode`, so moving away from the `any` return type should be pretty safe.
hwillson
added a commit
that referenced
this pull request
Feb 4, 2020
This commit modernizes/fixes the existing TypeScript declaration file as follows: - The module declaration now better represents how exports are currently setup, by using module augmentation to give access to helper functions that are added to the `gql` function itself. - Backwards compatibility has been maintained by re-exporting helper functions. - Stronger typing changes; the first param of the `gql` template literal is now a read only string based array, and the `gql` return type is a `DocumentNode`. We're leveraging TS' [import types](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-9.html#import-types) functionality to reference the `DocumentNode` type, which will help avoid issues like the previously reverted attempts to do this in #151 and #196. - While the new `gql` type changes could in theory be considered breaking, they really shouldn't be in practice. Tagged template literals enforce the use of an immutable array of strings, which means that even though `literals` was `any` before, the param should only ever been an array of strings. Along the same lines, the `gql` function has only ever returned a `DocumentNode`, so moving away from the `any` return type should be pretty safe.
hwillson
added a commit
that referenced
this pull request
Feb 4, 2020
* Update/fix the existing TS declaration file This commit modernizes/fixes the existing TypeScript declaration file as follows: - The module declaration now better represents how exports are currently setup, by using module augmentation to give access to helper functions that are added to the `gql` function itself. - Backwards compatibility has been maintained by re-exporting helper functions. - Stronger typing changes; the first param of the `gql` template literal is now a read only string based array, and the `gql` return type is a `DocumentNode`. We're leveraging TS' [import types](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-9.html#import-types) functionality to reference the `DocumentNode` type, which will help avoid issues like the previously reverted attempts to do this in #151 and #196. - While the new `gql` type changes could in theory be considered breaking, they really shouldn't be in practice. Tagged template literals enforce the use of an immutable array of strings, which means that even though `literals` was `any` before, the param should only ever been an array of strings. Along the same lines, the `gql` function has only ever returned a `DocumentNode`, so moving away from the `any` return type should be pretty safe. * Changelog update
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request Labels