chore(gatsby): Create type declarations for gatsby plugin files #4928
Conversation
size-limit report 📦
|
| !gatsby-browser.d.ts | ||
| !gatsby-node.d.ts |
There was a problem hiding this comment.
Question: Do we want to include these declaration files in the tarball? If yes, then we need to adjust the Gatsby-specific prepack script to copy them to build, too. Currently they do not end up in the tarball. Or is there another reason why we're adding them to .npmignore?
There was a problem hiding this comment.
Do we want to include these declaration files in the tarball?
I was on the fence about this. I opted for including them because they're useful for debugging, but I don't feel strongly about it. What do you think?
If yes, then we need to adjust the Gatsby-specific prepack script to copy them to build, too.
Oh, good catch. Unless you think it's a terrible idea to add them, I'll fix this.
There was a problem hiding this comment.
I think it can't hurt to include them. Don't know enough about Gatsby to know how many people would need them but if we're already producing them why not. We have to copy them to build/types to be found by the types entry point, i think, right?
There was a problem hiding this comment.
One thing just came to my mind: If, in the tarball, they end up in build/types, we could just adjust tsconfig.plugin.json to output them to build/types, right? Then we don't have to adjust Gatsby's prepack.ts.
There was a problem hiding this comment.
We have to copy them to
build/typesto be found by thetypesentry point, i think, right?
You know, this is an excellent question, to which I don't actually know the answer. ts-jest finds them where they are, and I'd have to experiment to see if it similarly finds them in types/. Another thought I have here, though, is that these two JS files are already outside of the entrypoint structure, so maybe it's fine that their declaration files are, too. Is the types endpoint even supposed to include them, given that main and module don't include the original source files?
There was a problem hiding this comment.
Update: I added them to the prepack script (and a few other places I'd forgotten about), but left them alongside the the source files they describe. I say we try it like this, and if it's a problem, someone will tell us. (Though my gut says it's fine.)
There was a problem hiding this comment.
Very good point, I didn't think about that. I say if it works for the source file this way, then why not for the declarations as well. Sounds good.
lobsterkatie
force-pushed
the
kmclb-create-gatsby-type-files
branch
3 times, most recently
from
6f657d3 to
c0591c6
Compare
lobsterkatie
force-pushed
the
kmclb-create-gatsby-type-files
branch
from
c0591c6 to
4b9f83d
Compare
This is a follow up to #4928, which added the creation of types files for the code in the gatsby SDK which lives outside of `src/`. One change which was missed was to have GHA include these new files in the build cache, so that they are available when tests are run. This fixes that oversight.
When creating a Gatsby plugin (which is what `@sentry/gatsby` actually is), there are certain files[1] which need to live at the package root level. Because they are written in JS (not TS) and don't live in `src/`, we have thus far more or less ignored them as far as type-ful processing goes. With the recent updates to TS, jest, and ts-jest, typechecking has now gotten stricter (especially in tests) and so now declaration files are needed for those gatsby-required, root-level files if we want to test them (which we do). This adds machinery to create, manage, and publish these declaration files. [1] https://www.gatsbyjs.com/docs/files-gatsby-looks-for-in-a-plugin/
This is a follow up to #4928, which added the creation of types files for the code in the gatsby SDK which lives outside of `src/`. One change which was missed was to have GHA include these new files in the build cache, so that they are available when tests are run. This fixes that oversight.
When creating a Gatsby plugin (which is what `@sentry/gatsby` actually is), there are certain files[1] which need to live at the package root level. Because they are written in JS (not TS) and don't live in `src/`, we have thus far more or less ignored them as far as type-ful processing goes. With the recent updates to TS, jest, and ts-jest, typechecking has now gotten stricter (especially in tests) and so now declaration files are needed for those gatsby-required, root-level files if we want to test them (which we do). This adds machinery to create, manage, and publish these declaration files. [1] https://www.gatsbyjs.com/docs/files-gatsby-looks-for-in-a-plugin/
This is a follow up to #4928, which added the creation of types files for the code in the gatsby SDK which lives outside of `src/`. One change which was missed was to have GHA include these new files in the build cache, so that they are available when tests are run. This fixes that oversight.
When creating a Gatsby plugin (which is what `@sentry/gatsby` actually is), there are certain files[1] which need to live at the package root level. Because they are written in JS (not TS) and don't live in `src/`, we have thus far more or less ignored them as far as type-ful processing goes. With the recent updates to TS, jest, and ts-jest, typechecking has now gotten stricter (especially in tests) and so now declaration files are needed for those gatsby-required, root-level files if we want to test them (which we do). This adds machinery to create, manage, and publish these declaration files. [1] https://www.gatsbyjs.com/docs/files-gatsby-looks-for-in-a-plugin/
This is a follow up to #4928, which added the creation of types files for the code in the gatsby SDK which lives outside of `src/`. One change which was missed was to have GHA include these new files in the build cache, so that they are available when tests are run. This fixes that oversight.
This adds a check to the beginning of the gatsby tests which makes sure that the necessary types files exist and creates them before starting the tests if they don't. Note: These files are not the normal files built by `yarn build:types` but additional ones made necessary by the structure gatsby plugins are required to have. See #4928.
When creating a Gatsby plugin (which is what `@sentry/gatsby` actually is), there are certain files[1] which need to live at the package root level. Because they are written in JS (not TS) and don't live in `src/`, we have thus far more or less ignored them as far as type-ful processing goes. With the recent updates to TS, jest, and ts-jest, typechecking has now gotten stricter (especially in tests) and so now declaration files are needed for those gatsby-required, root-level files if we want to test them (which we do). This adds machinery to create, manage, and publish these declaration files. [1] https://www.gatsbyjs.com/docs/files-gatsby-looks-for-in-a-plugin/
This is a follow up to #4928, which added the creation of types files for the code in the gatsby SDK which lives outside of `src/`. One change which was missed was to have GHA include these new files in the build cache, so that they are available when tests are run. This fixes that oversight.
This adds a check to the beginning of the gatsby tests which makes sure that the necessary types files exist and creates them before starting the tests if they don't. Note: These files are not the normal files built by `yarn build:types` but additional ones made necessary by the structure gatsby plugins are required to have. See #4928.
When creating a Gatsby plugin (which is what
@sentry/gatsbyactually is), there are certain files which need to live at the package root level. Because they are written in JS (not TS) and don't live insrc/, we have thus far more or less ignored them as far as type-ful processing goes. With the recent updates to TS, jest, and ts-jest, typechecking has now gotten stricter (especially in tests) and so now declaration files are needed for those gatsby-required, root-level files if we want to test them (which we do).This adds machinery to create, manage, and publish these declaration files.