Native TypeScript support #18983
-
|
TypeScript is fantastic and has been gaining a lot of popularity. One oft requested feature in Gatsby has been native TypeScript support1. We see no reason to not support it out of the box so let's discuss how to make this happen. Note
To do
Foot notesRelated issues#16310, #15277, #14185, #13436, #1457, #10452 Related PRsRelated pluginsgatsby-plugin-typescript |
Beta Was this translation helpful? Give feedback.
Replies: 34 comments
-
|
Is it supporting through re writing the whole in |
Beta Was this translation helpful? Give feedback.
-
|
@anikethsaha This wouldn't involve rewriting the gatsby code base. We're discussing the possibility of adding native TypeScript support for userland code. |
Beta Was this translation helpful? Give feedback.
-
|
I think this would be really helpful for those of us who write TypeScript and ❤️Gatsby. I'm particularly excited about these two potential changes: Support
|
Beta Was this translation helpful? Give feedback.
-
Support using |
Beta Was this translation helpful? Give feedback.
-
|
maby we can make a |
Beta Was this translation helpful? Give feedback.
-
Yessssss! Been trying out #1457 (comment) and https://gist.github.com/clarkdave/53cc050fa58d9a70418f8a76982dd6c8 as a "good enough" solution for now. Official support would be absolutely wonderful. |
Beta Was this translation helpful? Give feedback.
-
|
The DTS support for Gatsby's API is pretty solid already also, though I think it might be worth thinking about how to document it for folks too, for example I got really far using indexed types like this: import { GatsbyNode } from "gatsby"
import * as path from "path"
export const createPages: GatsbyNode["createPages"]
= async ({ graphql, actions }) => {
const { createPage } = actions
const blogPost = path.resolve(`./src/templates/blog-post.tsx`)
const result = await graphql(`
{
allMarkdownRemark(sort: { fields: [frontmatter___date], order: DESC }, limit: 1000) {
edges {
node {
fields {
slug
}
... |
Beta Was this translation helpful? Give feedback.
-
|
I'd love to understand more of the details of how the Core Team is considering implementing this! Seems like there are three potential approaches:
About a year ago, I researched this a lot to set up a lerna-managed monorepo using TypeScript. We landed on using The only place we've had trouble with |
Beta Was this translation helpful? Give feedback.
-
This sounds interesting. I dont think typescript compiler will fir here. |
Beta Was this translation helpful? Give feedback.
-
Thats what im saying seeing as we already have |
Beta Was this translation helpful? Give feedback.
-
|
For added example there can be a if(!gatsby-ts.js){
// force stop of running anything typescript related
console.log('We see you have chosen to opt-out of using Typescript for this project');
}else {
// run typescript file here
}just a thought and an example is all this ovi is a WIP but yea |
Beta Was this translation helpful? Give feedback.
-
With this example, is it possible to go back to opting into TypeScript, or is this like "ejecting?" |
Beta Was this translation helpful? Give feedback.
-
|
@maecapozzi what do you mean im not understanding sorry |
Beta Was this translation helpful? Give feedback.
-
|
YES! Please. I love Gatsby and I love TypeScript. I even created a starter that used Native support would be awesome, specially having code not compile if there are typing errors instead of having to run tsc manually every time. |
Beta Was this translation helpful? Give feedback.
-
|
@msallent I recommend trying |
Beta Was this translation helpful? Give feedback.
-
It's not like you would need a magic gatsby-plugin for this. Just use The problem is that |
Beta Was this translation helpful? Give feedback.
-
|
Just a reason for adding TypeScript support to gatsby-config etc, would be codesharing. Eg, a fair few plugins have options that require some more complex code, and this is often then duplicated across TypeScript and JavaScript files. It being in TypeScript means you can include it from the rest of the codebase, without having to maintain a second JS version (or lose type safety all together) |
Beta Was this translation helpful? Give feedback.
-
|
Just to link everything, I wrote on the Gatsby blog a little bit about TS + Gatbsy: https://www.gatsbyjs.org/blog/2020-01-23-why-typescript-chose-gatsby/ |
Beta Was this translation helpful? Give feedback.
-
|
Announcing the gatsby-plugin-typegen v1 is finally released!! https://github.com/cometkim/gatsby-plugin-typegen
This plugin helps using static/page queries with type-safety out-of-box. Hope you enjoy :) |
Beta Was this translation helpful? Give feedback.
-
|
I'm really looking forward to having OOTB Typescript support with Gatsby. Until then: The beta version of https://github.com/Js-Brecht/gatsby-plugin-ts-config Now you can write all of your config files in Typescript! It definitely needs a lot of testing out in the real world, so if you feel like giving it a whirl, and you run into problems, please report them! |
Beta Was this translation helpful? Give feedback.
-
|
@cometkim @Js-Brecht Awesome work. I wonder how much of your work would be worth bringing into core, and how much should stay a plugin. |
Beta Was this translation helpful? Give feedback.
-
|
@ascorbic Typegen plugin's emitting and code-fixing features can be unnecessary overhead for users who don't want to. And this is already being handled almost using Gatsby API, there's no big problem yet to use it from the outside. (I think it's rather decoupled well) But moving the package into the Gatsby monorepo would be ok. The next big milestone I think is enhanced code-fixing and schema customization. I wrote every type definitions for Gatsby API every time I use them such as sore actions and resolver context, especially typing the resolver context would be pretty big. It's desirable that these type definitions are eventually merged into the Gatsby core. |
Beta Was this translation helpful? Give feedback.
-
|
@ascorbic I'm all for bringing something similar to However, this would definitely need to be something a user can opt in to, so there would need to be a pre-build hook, or some other method, for configuring Typescript support aside from, and before, the usual Obviously, a great deal of work would have to be done to integrate 1 That particular issue doesn't have a lot of bearing on Gatsby, because Gatsby configuration files wouldn't have nearly the surface area as a set of tests, and the execution method is different; but I think performance as a whole will probably benefit from their work there. In the core, |
Beta Was this translation helpful? Give feedback.
-
|
FWIW: I think it's fine for the built-in support for TypeScript to come through the babel plugin, it's how it's done in react/react-native/next/jest etc. Doing this means only one or two extra (small) deps for Gatsby itself vs the 8mb monolith of adding TypeScript and then additional tooling like ts-node. Given that Gatsby already has the babel pipeline setup for JSX, it's not a big distance then between JS and TS users. |
Beta Was this translation helpful? Give feedback.
-
|
And it will soon have babel support by default. Just need to finish the docs. |
Beta Was this translation helpful? Give feedback.
-
It would be great! |
Beta Was this translation helpful? Give feedback.
-
|
Hi folks, I'm thinking of the next of my plugin gatsby-plugin-typegen. The plugin, unlike other plugins, doesn't run the codegen watcher, it integrates deeper into the Gatsby lifecycle and runs codegen directly, so it's much faster and smoother and it doesn't hurt development experience such as hot reloading. I am aware of some bugs in it but it still works. The downside of this approach is that it is sensitive to changes in the core behavior. I love Gatsby's content sourcing and enjoy the power of it and fragment colocation. The last piece is definitely a strong typing support, so I hope we can support this. I'm also thinking about the typings generated by the experimental File system API. The easiest way to support all the cases in the user node is to make it from the core, or Make it from third-party requires very uncertain reverse engineering and code analysis. I'd like to implement the next version in a reliable way as possible. I'm wondering if there is a possibility to port my plugin to the Gatsby core. |
Beta Was this translation helpful? Give feedback.
-
|
@cometkim Have you talked to @acao ? They are working on a VSCode GraphQL extension and a gatsby plugin that would generate typings if I remember correctly. |
Beta Was this translation helpful? Give feedback.
-
|
Hi! We're in the first phase of "TypeScript All The Things" for Gatsby. You'll be able to write all files with TypeScript. Please go to #34613 and give it a try. In the next phase we'll look at having better support for GraphQL codegen. You can watch the RFC discussion category for this or our changelog + Twitter to see when this lands. |
Beta Was this translation helpful? Give feedback.
-
|
Hey, we're now in the second phase of "TypeScript All The Things"! Since Gatsby v4.9 you're able to use TS in Soon you'll be able to use built-in typegen in Gatsby! Give this a try: RFC: GraphQL TypeScript Generation |
Beta Was this translation helpful? Give feedback.
Hey, we're now in the second phase of "TypeScript All The Things"!
Since Gatsby v4.9 you're able to use TS in
gatsby-*files 🎉 https://www.gatsbyjs.com/docs/reference/release-notes/v4.9/Soon you'll be able to use built-in typegen in Gatsby! Give this a try: RFC: GraphQL TypeScript Generation