-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(gatsby): Expose typescript transpiler to default site in plugin list #26452
feat(gatsby): Expose typescript transpiler to default site in plugin list #26452
Conversation
@vladar do you know who I can talk to to try to get some attention on this? With the new paradigm, things are a bit more...opaque here. This issue is causing me quite a few headaches, so it would be great to get some sort of solution to it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @Js-Brecht !
Thanks for suggesting this 👍 The code looks good solid me.
I think you are right and we should allow to opt-out of internal plugins like Typescript. I guess the main question here is if a new config option is a way to go here. Makes sense to me but I'd like to hear other opinions before we merge this.
Yeah, I wasn't really sure where else it would go. One other option I didn't really consider was an environment variable; but this is something that would generally be a permanent setting, as opposed to something that you would switch on/off. If I needed to rely on an environment variable in a project where I wanted to turn off the default typescript transpiler, I would probably wind up doing checks for it (or setting it) in |
Another possible option is to disable the plugin this way: {
resolve: `gatsby-plugin-typescript`,
options: {
disable: true
}
} It is more explicit and also can be applied to other internal plugins consistently. Do you see any pitfalls with this approach? |
I could see how requiring another dependency be installed that you're not really using could be annoying. It's included in Gatsby's dependencies now, but when using other package managers like pnpm or yarn2, you'd have to also have it installed in your project's deps or the build will fail. Not really a blocker, and since it's a one-time setup it wouldn't be any real overhead. One way around that would be to skip resolution for "disabled" internal plugins. That adds another layer of complexity to the plugin/theme resolution that I don't really think this issue warrants, though 🤷♂️ |
This seems like the easiest solution, right now. Expanding the config to enable/disable pieces of gatsby seems like a good approach but it takes planning and quite some resources to get it right. Something I don't think we'll going to prioritize. If we add typescript to the config like you did, it means we have to support this for a while... (we cans say yes but we don't know what issues it might bring in the future) How do we feel about:
When typecheck is true we will use ts-loader instead of babel-preset-typescript. (I don't know if it's that simple) |
I like that idea; it would almost be that simple. Since Typescript transpiling would then rely on If this is the route that's decided, I would have a couple questions regarding implementation:
I would also move the default inclusion above |
@Js-Brecht let's start with moving the typescript plugin higher in the chain so you can at least remove it yourself. Could you open a new issue with this discussion as I think we'll have to think it through. What problems we could see on the way with every approach. I'll put some effort to move this forward. |
d90c551
to
95451c7
Compare
Okay, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! Thanks for the back and forth!
Successfully published:
|
Description
Provides an option to disable the automatic set up of
gatsby-plugin-typescript
.When
gatsby-plugin-typescript
is enabled, it disallows the use of any other Typescript transpiler (with type-checking enabled). This means that using something likets-loader
with Typescript transformer plugins is impossible. In order to allow this again,gatsby-plugin-typescript
needs to be disabled.There were a few options I could see for achieving this:
Move the logic that adds
gatsby-plugin-typescript
to the plugin array abovedefault-site-plugin
.gatsby-config
api.Webpack config post-processing (i.e. afteronCreateWebpackConfig
)👍 Automatically handle typescript loaders, no matter where they're added👎 Very error prone. Likely impossible to account for all circumstancesAdd a new "plugin filter" or "webpack loader filter" API👍 More future proof👎 Seemed like a pretty major API changeAdd a new configuration value togatsby-config
.👍 Fixes the issue at the root👍 End-user experience is much, much nicer👎 Increases the surface area of thegatsby-config
api.I opted for number 4 because it just made the most sense to me.The end-user experience is much better than the others.Why force the user to filter out a loader in the webpack config. It's counter-intuitive to add loaders, then turn around and remove them. Means more moving parts that don't really need to be there.The default behavior remains the same as originally designed. Unless people need it, they can continue on without ever caring that the feature exists.Implementation itself was not difficult, nor is the process difficult to understand.Documentationdocs/gatsby-config.mdRelated Issues
Fixes #26027