refactor: migrate react tests to typescript

[ocavue]

Changes

Part of #16241

Since everyone is working on the unit tests under packages/astro/, let me do something else and migrate the integration tests under packages/integrations/react/.

---

The React test migration itself is easy and boring: only 3 files to change. However, I want to use it as an example to show that we can migrate integration tests in smaller PRs, contrary to what the original issue suggests:

Once unit tests are ported, we move to integration tests. This might need to require a one-shot PR because our loadFixture utility is used in various packages.

I achieve this by using TypeScript's Project References feature. Basically, it involves splitting the whole monorepo into smaller TypeScript "projects". Each tsconfig.json file with composite: true represents one TypeScript "project".

Note

A "TypeScript project" and a "PNPM monorepo workspace package" are different concepts.

• In TypeScript, a tsconfig.json represents a TypeScript project, and different projects are connected via the references field in tsconfig.json.
• In PNPM, a package.json represents a workspace package, and different packages are connected via dependencies/devDependencies in package.json.
• Usually, people put one or more TypeScript projects in a package. For example, Vite's official React TypeScript template is one package (package.json) with two TypeScript projects (tsconfig.app.json and tsconfig.node.json).

In this PR, I've added/modified the following TypeScript projects:

New projects:

• .github/scripts/tsconfig.json — for .github/scripts/
• scripts/tsconfig.json — for repo-level scripts/ (replaces the old scripts/jsconfig.json)
• packages/integrations/react/tsconfig.test.json — for React integration tests, and it imports and uses the loadFixture utility from another project.

Modified projects (now composite: true with references):

• packages/astro/tsconfig.json
• packages/astro/tsconfig.test.json (where loadFixture utility is defined)
• packages/astro/test/types/tsconfig.json

The references graph between these projects looks like this:

flowchart BT
    subgraph astro["packages/astro"]
        astroSrc["tsconfig.json<br/><i>(src)</i>"]
        astroTest["tsconfig.test.json<br/><i>(unit tests)</i>"]
        astroTypes["test/types/tsconfig.json<br/><i>(type tests)</i>"]
    end

    subgraph react["packages/integrations/react"]
        reactTest["tsconfig.test.json<br/><i>(integration tests)</i>"]
    end

    subgraph scripts["scripts/"]
        scriptsCfg["tsconfig.json"]
    end

    subgraph ghScripts[".github/scripts/"]
        ghScriptsCfg["tsconfig.json"]
    end

    astroTest -- references --> astroSrc
    astroTest -- references --> scriptsCfg
    reactTest -- references --> astroTest
    scriptsCfg -- references --> ghScriptsCfg

Loading

tsc --build instead of tsc --project

I've changed some scripts from tsc --project to tsc --build. This is required by the Project References feature: tsc --project only type-checks the single tsconfig.json you point it at and ignores any references it declares, whereas tsc --build walks the references graph and type-checks each referenced project in dependency order, reusing .tsbuildinfo caches for incremental rebuilds.

I've also added a repo-level typecheck:tests script (pnpm -r typecheck:tests) so that CI runs the type check across all workspace packages that define one, rather than only packages/astro/. For now, only two packages has typecheck:tests.

Testing

CI all green

Docs

No docs needed.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 658be10

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[matthewp]

I'm not familiar with project references but the idea seems solid to me.

[ocavue]

Notice that ._cache won't be published to NPM.

https://docs.npmjs.com/cli/v10/configuring-npm/package-json#files

I put the tsbuildinfo.json under dist/ so that developers can more easily remove the dist/ to clean both the built .d.ts files and the cached index file tsbuildinfo.json.

[ocavue]

I edited this line because somehow astro is still using @types/node v18, which doesn't contain 'test' for this field.

cat node_modules/@types/node/package.json | jq '.version'
"18.19.130"

We should update @types/node, but that's out of the scope of this PR.

[florian-lefebvre]

Maybe I'm misunderstanding but it looks a bit odd that the test tsconfig for the react integration needs a reference to the astro test tsconfig.

In my original WIP PR (as POC), I had a root test tsconfig that all tests tsconfigs would extend. Do you have any opinions on whether project references are better than this?

To be clear I'm not against! Project references are useful, I'm just trying to see if it's the best solution

[florian-lefebvre]

Interesting, we were using src because zod could cause some issues. If that's not the case anymore, I'm glad!

[florian-lefebvre]

Why is this needed?

[ocavue]

We're importing package.json in packages/astro/test/units/cli/index.test.ts:8, thus we need to import package.json in one of the tsconfig.json file.

Since we only use package.json in tests, I will move this "include": ["package.json"] from packages/astro/tsconfig.json to packages/astro/tsconfig.test.json.

update: done in be3f770

[ematipico]

.github/scripts/tsconfig.json — for .github/scripts/

I don't think we want that though, otherwise we would start getting type check issues for JS files. Maybe what we want is to port them to TS in a later stage.

Can we revert it?

[ocavue]

.github/scripts/tsconfig.json — for .github/scripts/

I don't think we want that though, otherwise we would start getting type check issues for JS files. Maybe what we want is to port them to TS in a later stage.

@ematipico

First, let me show the import graph between these files:

Step 1: packages/integrations/react/tsconfig.test.json → packages/astro/tsconfig.test.json

packages/integrations/react/test/react-19-preloads.test.ts:3

import { loadFixture } from '../../../astro/test/test-utils.js';

Step 2: packages/astro/tsconfig.test.json → scripts/tsconfig.json

packages/astro/test/test-utils.js:8

import { CILogger } from '../../../scripts/testing/github-utils.js';

Step 3: scripts/tsconfig.json → .github/scripts/tsconfig.json

scripts/testing/github-utils.js:5

import { setSummary } from '../../.github/scripts/utils.mjs';

Summary

packages/integrations/react/test/react-component.test.ts (owned by `packages/integrations/react/tsconfig.test.json`)
  └─▶ packages/astro/test/test-utils.js (owned by `packages/astro/tsconfig.test.json`)
        └─▶ scripts/testing/github-utils.js (owned by `scripts/tsconfig.json`)
              └─▶ .github/scripts/utils.mjs (owned by `.github/scripts/tsconfig.json`)

---

Since .../react-component.test.ts imports .github/scripts/utils.mjs, and we want to type check the first file, we need to know the types of all files in this chain, including those .mjs files under .github/scripts. That's why I added a tsconfig.json under .github/scripts.

we would start getting type check issues for JS files

Yes. In this PR, I'm already type checking these JS files and fixed one issue I found, as shown in this comment.

Maybe what we want is to port them to TS in a later stage.

Porting these scripts from JS to TS won't eliminate the need for adding a tsconfig.json, as long as the import graph shown above stays the same.

Can we revert it?

If I simply delete .github/scripts/tsconfig.json, the CI type checking will fail.

---

I admit it's weird to put a tsconfig.json file under .github/scripts; it's just the easiest path I could take to make this PR green.

Taking a step back, I think the better approach is to ask two questions:

• (A): In Step 2, why do we want to import an API from a script in a unit/integration test? Can we cut this dependency by, for example, copy-pasting the CILogger implementation or moving it into a package?

  If we don't need Step 2, then we don't need scripts/tsconfig.json, and thus we don't need .github/scripts/tsconfig.json. These scripts are still being just scripts are they are not part of the TypeScript type checking graph.

• (B): In Step 3, why do we put scripts in two different locations (scripts/ and .github/scripts/)? Can we just put all of them under scripts/?

  If we merge .github/scripts/ and scripts/, then we don't need both scripts/tsconfig.json and .github/scripts/tsconfig.json. We can just keep one scripts/tsconfig.json file. We're still type checking these scripts, we just reduce a tsconfig.json file.

What do you think? (A) seems a bit complex, and (B) seems easier.

[ematipico]

@ocavue are you up for some cleanup once the tests are ported to TypeScript? As far as I can tell, you created this so that the porting doesn't have to be massive, which I really appreciate. However, I suppose once we're done, we can go back to a less complex setup, correct?

[ocavue]

@florian-lefebvre

it looks a bit odd that the test tsconfig for the react integration needs a reference to the astro test tsconfig.

In the current PR, packages/astro/test/test-utils.js is owned by packages/astro/tsconfig.test.json. Since the React integration tests need to use .../test-utils.js, they need a reference to packages/astro/tsconfig.test.json.

I guess this feels odd because packages/astro/tsconfig.test.json also owns packages/astro/test/units/*.test.ts, and those .../units/*.test.ts files are unrelated to the React integration.

I can add another tsconfig.json file to make the reference graph clearer:

• packages/astro/tsconfig.test-utils.json (new) includes files like .../test-utils.js
• packages/astro/tsconfig.test.json (already present in the current PR) includes all *.test.ts files under packages/astro/. It would need a reference to .../tsconfig.test-utils.json
• packages/integrations/react/tsconfig.test.json (already present in the current PR) includes all *.test.ts files under packages/integrations/react/. It would also need a reference to .../tsconfig.test-utils.json

Would you prefer this approach? It is a trade-off between (A) having fewer tsconfig.json files, and (B) having a more accurate reference graph. I'm okey with both directions.

---

I had a root test tsconfig that all tests tsconfigs would extend. Do you have any opinions on whether project references are better than this?

In general, putting code from multiple PNPM packages (package.json) into the same TypeScript project (tsconfig.json) is not a good idea, for two reasons:

1. Performance. With project references, TypeScript can catch changes at the right boundary. When you change an upstream TypeScript file and run tsc --build, it does not need to rebuild the entire monorepo. It only needs to rebuild the affected layer and its dependents.
2. Preventing global type conflicts. For example, the browser and Node.js versions of setTimeout have different type definitions: the browser version returns a number, while the Node.js version returns an object. Vue also used to register global JSX types until fairly recently, which could cause type conflicts if you used Vue and React in the same TypeScript project. If we split them into separate projects with project references, we avoid this kind of problem.

[ocavue]

are you up for some cleanup once the tests are ported to TypeScript

@ematipico Yes, I can do the cleanup afterward. The astro repo is slow when I open it locally in VSCode for features like jump definition, and I believe I can improve this as well with a better and less complex TypeScript setup.

[ematipico]

Waiting for @florian-lefebvre approval before merge