feat(types): expose GraphQlQueryResponseData type #256
Conversation
src/index.ts
Outdated
| @@ -13,6 +13,8 @@ export const graphql = withDefaults(request, { | |||
| url: "/graphql", | |||
| }); | |||
|
|
|||
| export { GraphQlQueryResponseData } from './types' | |||
There was a problem hiding this comment.
Is there a 🆒 and easy way to test this type is being exposed properly at Continuous Integration level?
This means, when somebody installing latest version of octokit/grapqhql.js will be able to write import { GraphQlQueryResponseData } from '@octokit/graphql.js'
(I know I can manually test it with pika's package but I was wondering if there's a way to integrate it at CI level)
There was a problem hiding this comment.
test this type is being exposed properly
The fact that you're doing export x from y means that it should be exported for use; if it isn't, then that represents a far bigger issue in TypeScript itself :)
The way to test this on our end would be to have a file doing the import - I'm not against this in a few places (like how we've got a typescript validation file in webhooks.js), but want to make sure we don't end up in a mindset that is us not trusting typescript, as that'll mean we have to write an import for everything we export which'll be really painful (since we'll effectively have to double the amount of coding we do, and defeat a huge part of the reason for using TypeScript)
There was a problem hiding this comment.
I see your point... I guess maintaining documentation would be enough in this case if we decide to remove at some point the exposure of something :)
There was a problem hiding this comment.
Good point! Maybe we could do a similar typescript verification test as we do in @octokit/rest?
oscard0m
added
Type: Feature
|
🎉 This PR is included in version 4.6.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
📝 Summary
Expose GraphQlQueryResponseData type
⛱ Motivation and Context
Fix #254