This was a major milestone of gatsby-plugin-typegen as a long time. Now it has become a reality.
Since the plugin code is fully ported to Gatsby, there is no difference in the default behavior. (the plugin has more options than Gatsby)
So should this project closed? Well I guess so.
But since there are still some unexplored topics among the plugin's goals, I'm aiming for one more major release. It will experiment in a different direction with Gatsby's built-in Typegen feature.
Language tools support
Gatsby is focusing on TypeScript support. I still see the Flow is still useful some in minor use cases. Actually it's much better than TypeScript as a type-cheker.
Also I enjoy experimenting with Alt-JS compilers like ReScript, Fable, ScalaJS.
Gatsby's plugin system is a good area to support minor use cases. Based on the Typegen service added to Gatsby core, I will write some RFC to get a stable plugin API to accommodate these minor use cases.
So If it will be configurable with gatsby-node API like Babel or Webpack config, these can all be replaced with independent GCG plugins.
Related:
87
Optimize output format
Right now the plugin is generating fairly heavy type codes with the basic GCG plugin configuration, but the information we need from Gatsby is very limited, leaving room to further optimize output for DX.
if the plugin can remove meaningless information from schema and emit incrementally per operation instead of merging all definitions into a single file, IO throughput and type inference performance can be greatly improved.
It might consider building a dedicated GCG plugin for this.
Experiment for theme composition
I use this plugin everyday, but it's almost useless for large-scale projects. Because large-scale Gatsby projects deal with data almost at the theme level.
It's one of the most difficult problems plugins face. And It's might difficult to come up with a universal solution that can be used by everyone. Anyway, it will be easier to experiment with various approaches and configuration options in the plugin area rather than the core.
GatsbyJS now provides builtin Typegen for GraphQL queries feature, which was ported from gatsby-plugin-typegen v3
This was a major milestone of gatsby-plugin-typegen as a long time. Now it has become a reality.
Since the plugin code is fully ported to Gatsby, there is no difference in the default behavior. (the plugin has more options than Gatsby)
So should this project closed? Well I guess so.
But since there are still some unexplored topics among the plugin's goals, I'm aiming for one more major release. It will experiment in a different direction with Gatsby's built-in Typegen feature.
Language tools support
Gatsby is focusing on TypeScript support. I still see the Flow is still useful some in minor use cases. Actually it's much better than TypeScript as a type-cheker.
Also I enjoy experimenting with Alt-JS compilers like ReScript, Fable, ScalaJS.
Gatsby's plugin system is a good area to support minor use cases. Based on the Typegen service added to Gatsby core, I will write some RFC to get a stable plugin API to accommodate these minor use cases.
So If it will be configurable with gatsby-node API like Babel or Webpack config, these can all be replaced with independent GCG plugins.
Related:
87
Optimize output format
Right now the plugin is generating fairly heavy type codes with the basic GCG plugin configuration, but the information we need from Gatsby is very limited, leaving room to further optimize output for DX.
if the plugin can remove meaningless information from schema and emit incrementally per operation instead of merging all definitions into a single file, IO throughput and type inference performance can be greatly improved.
It might consider building a dedicated GCG plugin for this.
Experiment for theme composition
I use this plugin everyday, but it's almost useless for large-scale projects. Because large-scale Gatsby projects deal with data almost at the theme level.
It's one of the most difficult problems plugins face. And It's might difficult to come up with a universal solution that can be used by everyone. Anyway, it will be easier to experiment with various approaches and configuration options in the plugin area rather than the core.
Related
166
167