More flexible default Typescript transpiler handling #26984
Replies: 2 comments
-
Hiya! This issue has gone quiet. Spooky quiet. 👻 We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 20 days since the last update here. Thanks for being a part of the Gatsby community! 💪💜 |
Beta Was this translation helpful? Give feedback.
-
@wardpeet This issue was supposed to be for additional discussion around this topic. I would hate to see it get closed before it gets addressed |
Beta Was this translation helpful? Give feedback.
-
Summary
I am opening this issue primarily for the purpose of tracking discussion regarding potential alternative ways to handle the "typescript by default" feature.
Motivation and Context
Adding
gatsby-plugin-typescript
to the plugin array by default causes issues when trying to use other methods for handling Typescript transpiling via Webpack.gatsby-plugin-typescript
removes all of the types from the code, so by the time another transpiler hits it (with type-checking enabled), transpiling the code will result in a litany of failures.In #26452, there was some discussion around different possible implementations of the "Typescript by default" feature. My thoughts were to use another property in
gatsby-config
, @vladar suggested alterations to how the plugin array is processed, and @wardpeet suggested thatgatsby-plugin-typescript
itself be altered to handle use cases that include typechecking (e.g. switch tots-loader
).For additional context regarding the issue where this started, see #26027
Method Examples
gatsby-plugin-typescript
before it happens.gatsby-config
apiPlugin array option
disable
option to determine whether or not to include a plugingatsby-plugin-typescript
in your project (for the sole purpose of disabling it), or special handling of internal plugins.gatsby-plugin-typescript
alteration (:+1: :+1:)typecheck === true
, usets-loader
.ts-loader
Beta Was this translation helpful? Give feedback.
All reactions