Gatsby use babel-preset-typescript which strips type information out of your code without doing typecheck. gatsby-plugin-ts use ts-loader, so you don't have to (1) worry about the caveats of babel-preset-typescript or (2) use an IDE / code editor that can typecheck for you.

It also generate typings for your graphql queries, make it easier to strengthen your code.

If you're already using something like VSCode and/or don't want to do typecheck in production, you can toggle off the typecheck option.

Originally belong to the same plugin, the codegen portion was extracted to gatsby-plugin-graphql-codegen so it can be used with the official typescript plugin. If you are already using gatsby-plugin-ts, you don't need gatsby-plugin-graphql-codegen.

It's up to your preference.

It's due to Gatsby internal. There's an effort to make typing more strict here.

You also may find the new optional chaining & nullish coalescing operator in typescript 3.7 helpful to deal with this.

Yes! You can also use node env to determine whether to enable these features.

// gatsby-config.js
{
  resolve: `gatsby-plugin-ts`,
  options: {
    codegen: false,
    typeCheck: process.env.NODE_ENV === 'development',
  }
},

Gatsby extract graphql queries statically and it only understand queries inside template literal. It's possible that tsc is transpiling your template literal to string concat quivalent. Check your tsconfig.json & make sure you have a setting similar to this:

"compilerOptions": {
  "target": "ES2018",    /* or at least ES2015 */
  "module": "ESNext",    /* or at least ES2015 */
  "lib": ["dom"],             /* <-- required! */
  "jsx": "preserve",          /* <-- required! */
  "moduleResolution": "node", /* <-- required! */
  /* other options... */
}

You'd have to update your tsconfig with the below options:

  "allowJs": true,
  "outDir": "./build"

The outDir option won't be used by ts-loader, but you may need it to satisfy vscode.

If you are using gatsby-plugin-ts, before you go off and install a bunch of babel plugins like a lot of tutorials suggest, check if your compilation target in tsconfig.json is too high (ESNext or ES2019).

With these targets, tsc will leave the new syntax as-is, which babel might not understand. Downgrade them to ES2018 should fix the issue; also make sure your IDE's typescript version is the same as the one listed in your package.json dependency.

Yes, but it's not easy at the moment. We're working on it; stay tuned!

We're trying to pin down why this happens, please share your experience in #36

If you are annoyed by this warning, set the documentPaths options as below:

// gatsby-config.js
{
  resolve: 'gatsby-plugin-graphql-codegen',
  options: {
    documentPaths: [
      './src/**/*.{ts,tsx}',
      './node_modules/gatsby-*/**/*.js',
    ],
  }
},

We will remove the .cache/fragments path and bump gatsby peer dependency version in a later release.

Update: Since 2.4.0, we've removed .cache/fragments & bump up gatsby peer dep.

If you see this error please run a gatsby clean to remove fragments in .cache, or set the documentPaths options as below:

// gatsby-config.js
{
  resolve: 'gatsby-plugin-graphql-codegen',
  options: {
    documentPaths: [
      './src/**/*.{ts,tsx}',
      './node_modules/gatsby-*/**/*.js',
    ],
  }
},

Are you using a monorepo? It's possible that the missing fragment's plugin is 'hoisted' (moved to workspace root's node_modules). A simple fix is use a nohoist config, supported by both lerna & yarn. Here's an example with yarn workspace, where gatsby-transformer-sharp is always installed in its project's node_modules.

in your root's package.json

"workspaces": {
  "packages": ["packages/*"],
  "nohoist": [
    "**/gatsby-transformer-sharp"
  ]
}