-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stricter type inference and enforcement? #16310
Comments
|
That explains the html thing. Thanks for the date tip. I'm still wondering why html is nullable to begin with, and whether these types get enforced via CLI complaining at me. |
yes would probably make sense to make it not nullable. // gatsby-node.js
exports.createResolvers = ({ createResolvers }) => {
createResolvers({
MarkdownRemark: {
html: {
type: 'String!',
}
}
})
} GraphQL will complain when there are null values on const { graphql, buildSchema } = require('graphql')
graphql(
buildSchema('type Query { html: String! }'),
'query { html }'
).then(result => console.error(result.errors)) |
Hi everyone. I'm with the author, many fields like Why? Because I'm full-blown on TypeScript and https://graphql-code-generator.com/ and it's indeed much easier to navigate all those deep trees of nodes, edges, JSON files, and other things when it's strongly typed, also, it's nice to be sure that everything is nicely typed and "there" and of a correct type based on typings generated from the schema, queries, fragments etc. Basically, the fact that 99% of the fields in So, I will be super happy if the types that plugins are generating will become stricter. |
@RIP21 |
@stefanprobst Can we get this tagged properly maybe? So it will be in backlog or so? Because it's kinda painful :) |
Not stale, still pain. |
This is still a problem. |
New to Gatsby and have been running into this too - it's definitely painful for TS sites! |
Hiya! This issue has gone quiet. Spooky quiet. 👻 We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here. Thanks for being a part of the Gatsby community! 💪💜 |
Hey again! It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it. Thanks again for being part of the Gatsby community! 💪💜 |
It's not stale. Thanks. |
We're moving official plugins to use the schema customization API like @stefanprobst mentioned. For now, you can do it yourself in gatsby-node.js. It's still going to be impossible to do this correctly 100% of the time. We could use inference and if a property is available everywhere mark it as non nullable. cc @vladar |
Yes, you can follow #20069 for schema customization updates. We will try to convert as much as possible to |
Hiya! This issue has gone quiet. Spooky quiet. 👻 We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here. Thanks for being a part of the Gatsby community! 💪💜 |
Hiya! This issue has gone quiet. Spooky quiet. 👻 We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here. Thanks for being a part of the Gatsby community! 💪💜 |
Not stale, dear bot. |
I'll close this in favor of #20069 as the original question was answered and nothing actionable is present. We'd be happy to receive PRs to update the plugins to use the stricter variant :) |
Is there a way to assume that every field seen in a frontmatter is non-nullable? It seems like that would be a reasonable option to have.
I solved it like this,
Which is fine.
But, it all works except for the
html
field which still ends up being nullable. Why? And, I'm not even sure why that is nullable in the first place. In what situation would the html be null?Also, will this schema be enforced in any way? If one of my blog posts, for example, are missing a
date
field will the CLI yell at me? I'm using this with graphql codegen for convenience, but that would be nice too.Thanks
The text was updated successfully, but these errors were encountered: