Open mosesoak opened 2 years ago
It seems strange that gatsby-node.ts
is getting hit by Webpack. I know that gatsby-node
is a watched dependency for the Webpack configuration, but that hasn't been an issue before. Can you share a reproduction?
Thanks for the reply, I'll work on a repro for you outside of our current projects, but can tell you this if it helps: we're using Twin.macro with Emotion, which adds Tailwind support, not sure if that interacts. Our babelrc is
{
"presets": ["@babel/preset-typescript", "babel-preset-gatsby"],
"plugins": [
[
"babel-plugin-root-import",
{
"rootPathSuffix": "src"
}
],
"babel-plugin-twin" // enables use of tw prop without `import 'twin.macro'`
]
}
That's all for the site build; i.e. in webpack land.
This plugin is meant to run before any of that stuff runs... this current version runs as soon as gatsby-config
is processed, which is before even onPreInit()
from gatsby-node
. gatsby-ts
runs before Gatsby itself even starts.
So you see why it is seems pretty strange that it would fail somewhere in the middle of the bootstrap or build. I have a feeling that they have added some extra parsing/processing later on in the bootstrap, and it's that particular point that doesn't like there being Typescript... but I won't know for sure until I can see how your project is structured, and then examine what they've changed in v4. (I honestly haven't even run v4 yet, except for the alpha)
Okay yes I see what you mean, and indeed this error happens very late in the build, after all the assets have been processed ... frustrating to test with our 5 minute build! It probably is specific to Gatsby 4.
A reproduction might be as simple as spinning up a starter and using this plugin in it.
I will give that a whirl as soon as I have a bit of time, but if I can’t reproduce the problem like that, I’ll definitely need one from you. I also can’t be certain when I’ll have the time to spin that up, so having a repro already ready to go would definitely speed up the process 🙂
Well, I hear you but Gatsby 4 train is a-comin', and all the plugin authors in the ecosystem are going to get issues like this one. After we found out that React 18 doesn't work correctly in Gatsby 4 yet we've decided to hold off on upgrading for a while, but once we do want to upgrade this plugin might end up being a blocker since we can use TS code in our config files with this on Gatsby 3. Again if I have time to spin up a repro I will but for now I can report that this happened in 2 separate projects I was trying to upgrade. Thank you again for your work on this valuable plugin, I wish Gatsby would just support TS in their config files already!
First-class typescript gatsby-config
& gatsby-node
support is coming soon. They're supposed to be working on it in the next week or two.
https://github.com/gatsbyjs/gatsby/discussions/31587#discussioncomment-1906686
Hey JS thank you for your work to bring Gatsby into the modern world. We've used both the plugin and the upcoming
gatsby-ts
module successfully in a few projects now, but wanted to report that our builds break when we add typescript code to the files.So like in
gatsby-node.ts
, import and export works and if we simply leave out TS code it all compiles. However, as soon as some types are added the compiler chokes.This is using all the latest Gatsby 4.52 etc.
Here it is failing on an "as" cast,
And here it is choking very hard on some types around the main export -- the error message has added some weird spaces and I even saw it error with a bunch of nonsense characters like numbers truncating some lines, so it's y'know babel barfing,
I tried adding the js config file and setting it to ts-node, with my standard script compiling options, but still got this webpack + babel error.