Generate exports file instead of namespace

[vimtor]

I will be nice to add an option generate a export files instead of a namespace called GatsbyTypes

That way one can simply import the necessary types directly.

[cometkim]

This has a story. v1 did that.

The main goal of this plugin is DX enhancement. I wanted to provide an auto-import to keep the module usecase, but because of the complexity due to so many possibilities of that approach, I replaced it with a way to use the global namespace.

I wondered if the module was still needed, but I couldn't find a case, so it was dropped because I wanted to keep the rest of the configuration as simple as possible.

But I admit someone may still need it. @vimtor Can you describe your case so that I can think of a specific way to provide it?

[cometkim]

See https://github.com/cometkim/gatsby-plugin-typegen/pull/47 for more details

[vimtor]

Hi @cometkim! As you might imagine each developer is a world.

To starts things off I am using Webstom, so I cannot use that cool looking vscode extension. (Nevertheless, there is an awesome plugin also for code completion and syntax highlight).

I would like to have the export file since I like organizing my React projects like this:

components/
   link.tsx
   index.ts
typings/
   entities.ts
   theme.ts
   index.ts

Then I simply import all my typings from the folder:

import { TaskEntity, DarkTheme } from 'typings'

I would like to create a graphql.ts file inside typings that export the query types. I've looked at other gatsby plugins but they rely on putting the generated code at the root level to avoid infinite rebuilding loops.

I know is such an edge case and maybe even impossible, but maybe giving the option such as:

{
  resolve: 'gatsby-plugin-typegen',
  options: {
    emitTypes: './src/typings/graphql.ts'
  }
}

Thanks for your response!

[zandaleph]

@cometkim Just adding my two cents here - Typescript now explicitly discourages namespaces: https://www.typescriptlang.org/docs/handbook/namespaces-and-modules.html

On top of that, as a VSCode user, it isn't picking up these global definitions by default. I'm not keen to add a bunch of config to both this plugin and my editor to make it work - basically, this plugin doesn't work out of the box for me because I can't just import definitions from a module like I did with gatsby-plugin-graphql-codegen. Since that plugin is now deprecated and pointing users here, and this plugin has no usage examples and doesn't just work, I'm forced to go learn graphql-code-generator if I want typesafe graphql queries in Gatsby.

Thanks for the plugin, I'll be borrowing code from it liberally but as written today it doesn't work for me.

[cometkim]

Typescript now explicitly discourages namespaces:

It's not to be used as a replacement for JavaScript objects and isn't relevant as long as the plugin deals only with types without any JavaScript semantics.

I mainly use coc.nvim, and I'm dogfooding this plugin with my coworkers using VSCode. This should work out of the box in any Gatsby project by default with no additional settings.

@zandaleph Can you provide me a reproduction that the plugin doesn't work properly?

I understand that there are use cases where you would like to use module semantics directly instead of global/namespaces, and I have plan to experiment various output modes in v3.x

[zandaleph]

Hey @cometkim , thank you so much for getting back to me so quickly!

So, once I changed to useStaticQuery it worked a bit better. Adding the plugin with no config to a freshly generated gatsby site results in something like this: https://github.com/zandaleph/bookish-carnival/tree/gatsby-plugin-typegen

npm run develop and npm run build both seem to work and add the correct parameterized type to useStaticQuery. That's pretty neat!

However, VSCode does not know where to find the definition of GatsbyTypes:

If there's a simple config to add to the plugin to tell vanilla vscode where to find these, I'd be set.

I'm excited to hear about expanded output modes in 3.x. My personal bias is to not have this much magic and to use module definitions to make these types importable. I'm still not quite sure how these definitions are visible to the compiler, though they obviously are since the build target works.

Thanks again!

[cometkim]

Ah I see, you don't even have tsconfig.json, I guess it will work after running tsc --init

[zandaleph]

Ah! I was lulled into too much a sense of security by Gatsby 3's new built-in typescript support. I knew it seemed too easy.

You nailed it, running npx tsc --init got VSCode happy right away. Thanks!