As mentioned on #5789, any component that has both a StaticQuery and a TS interface (or type) declaration will flat out fail to compile the GraphQL fragments/queries.
Inserting semicolons inside the interface/type declaration seems to be the "solution" at the moment... but it's a hacky workaround at best, and I'm not sure that breaking a linting rule is a true solution to this problem.
Other than that, this error log appears:
error There was a problem parsing "/Users/resir014/etc/repos/resir014/gatsby-starter-typescript-plus/src/layouts/index.tsx"; any GraphQL fragments or queries in this file were not processed.
I've also discovered this while testing out my typescript-plus starter with v2 of Gatsby. I'm in the early stages of converting it, and honestly it's not a big deal of an issue, but still a weirdness that threw me off regardless...
next branch of gatsby-starter-typescript-plus../layouts/index.tsx component.StaticQueryProps type.GraphQL fragments/queries should be processed, regardless of whether or not the interface/type has a semicolon.
GraphQL fragments/queries aren't processed when semicolons don't exist, and page shows up the Loading message.
System:
OS: macOS High Sierra 10.13.5
CPU: x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
Shell: 5.5.1 - /usr/local/bin/zsh
Binaries:
Node: 8.11.3 - /usr/local/opt/node@8/bin/node
Yarn: 1.7.0 - /usr/local/bin/yarn
npm: 5.6.0 - /usr/local/opt/node@8/bin/npm
Browsers:
Chrome: 67.0.3396.87
Safari: 11.1.1
npmPackages:
gatsby: ^2.0.0-beta.11 => 2.0.0-beta.11
gatsby-image: ^2.0.0-beta.2 => 2.0.0-beta.2
gatsby-plugin-canonical-urls: ^2.0.0-beta.2 => 2.0.0-beta.2
gatsby-plugin-react-helmet: ^3.0.0-beta.2 => 3.0.0-beta.2
gatsby-plugin-sharp: ^2.0.0-beta.2 => 2.0.0-beta.2
gatsby-plugin-styled-components: ^3.0.0-beta.2 => 3.0.0-beta.2
gatsby-plugin-typescript: ^2.0.0-beta.4 => 2.0.0-beta.4
gatsby-remark-copy-linked-files: ^2.0.0-beta.2 => 2.0.0-beta.2
gatsby-remark-images: ^2.0.1-beta.3 => 2.0.1-beta.3
gatsby-remark-prismjs: ^3.0.0-beta.2 => 3.0.0-beta.2
gatsby-remark-responsive-iframe: ^2.0.0-beta.2 => 2.0.0-beta.2
gatsby-remark-smartypants: ^2.0.0-beta.2 => 2.0.0-beta.2
gatsby-source-filesystem: ^2.0.1-beta.3 => 2.0.1-beta.3
gatsby-transformer-json: ^2.1.1-beta.2 => 2.1.1-beta.2
gatsby-transformer-remark: ^2.1.1-beta.2 => 2.1.1-beta.2
gatsby-transformer-sharp: ^2.1.1-beta.2 => 2.1.1-beta.2
npmGlobalPackages:
gatsby-cli: 1.1.58
gatsby-config.js: See repo.
package.json: See repo.
gatsby-node.js: See repo.
gatsby-browser.js: See repo.
gatsby-ssr.js: See repo.
This is mysterious behaviour indeed. The existence of a PageQuery or StaticQuery doesn't seem to matter. I can reproduce the problem without either. Also compiling with tsc works just fine without the semicolon.
@dennari Yeah. One thing to note is that Gatsby switched to using the Babel TS transpiler for v2 instead of tsc. So I assume... it could be a problem with that?
If that's the case, then #6157 might also be related.
Yep, it's definitely a problem with that. I actually tried to reproduce it with only babel-preset-typescript with no luck. There's something more complex going on.
It seems to be happening when Gatsby is parsing the GraphQL queries, but I have a limited understanding how/when that actually happens. Could someone point to an explanation?
Ok I think I have this figured out. When Gatsby is parsing the queries, it's using @babel/parser with a fixed set of plugins which doesn't include typescript. It does include flow though and amazingly some simple interface declarations (like the one in the using-typescript example) get parsed ok even with the flow parser.
This is quite subtle though, since if the file doesn't include the string "graphql" the parsing is skipped. This is the reason why I didn't run to this problem earlier myself.
Anyway, this really means that typescript parsing is quite broken atm. For example the issue #6157 is clearly related to this.
I can confirm the fixes in #6335 resolves this issue.
Thanks for your hard work @dennari! ❤️