feat(tools): enable typecheck on all TypeScript files

[huyenltnguyen]

Checklist:

• I have read freeCodeCamp's contribution guidelines.
• My pull request has a descriptive title (not a vague title like Update index.md)

I noticed that if we have a TS error in a test or a storybook file, pnpm run typecheck would ignore them.

This PR:

• Updates the TypeScript and Rollup config to enable typecheck on all TypeScript files, while still keeping irrelevant types out of the package bundle.
• Converts Jest config and setup files to TypeScript - This is a change I've been wanting to make. I didn't intend to include it in this PR, but I had to in order to run typecheck on test files (details in the PR comments)
• Adds back ts-node - It is unfortunately a buddy of Jest (ref)
  • 
• Removes tsx

Testing

• Make a TS error in a *.test.tsx or a *.storybook.tsx file
• Run pnpm run typecheck and check if it throws an error
• Run pnpm run build and check if types in test and storybook files are included in the bundle

[socket-security]

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
npm/[email protected]	environment Transitive: filesystem, shell	+1	50.3 kB	kentcdodds
npm/[email protected]	None	+1	143 kB	evilebottnawi
npm/[email protected]	Transitive: environment	+20	3.69 MB	benmonro
npm/[email protected]	filesystem Transitive: environment	+30	3.4 MB	simenb
npm/[email protected]	Transitive: eval	+66	9.22 MB	ljharb
npm/[email protected]	environment	0	118 kB	gnoff
npm/[email protected]	filesystem Transitive: eval	+63	5.01 MB	ljharb
npm/[email protected]	filesystem Transitive: environment	+31	3.27 MB	testing-library-bot
npm/[email protected]	environment, filesystem Transitive: eval, shell, unsafe	+63	9.8 MB	eslintbot
npm/[email protected]	environment, filesystem, shell	0	3.61 kB	typicode
npm/[email protected]	Transitive: environment, eval, filesystem, network, shell, unsafe	+67	8.62 MB	simenb
npm/[email protected]	Transitive: environment, eval, filesystem, network, shell, unsafe	+166	12.9 MB	simenb
npm/[email protected]	Transitive: environment, filesystem, shell	+24	1.12 MB	okonet
npm/[email protected]	environment Transitive: filesystem, shell	+7	237 kB	bret

🚮 Removed packages: npm/[email protected], npm/[email protected], npm/[email protected]

View full report↗︎

[huyenltnguyen]

Updated the file following https://jestjs.io/docs/configuration.

[huyenltnguyen]

You can read how I went through the rabbit hole below, but here is the TL;DR version: The tsc command threw a lot of errors when checking test files. This was because it couldn't find the type definitions of @testing-library/jest-dom. Since @testing-library/jest-dom is imported into this file, I reckoned tsc couldn't see the types simply because it ignores JS files, so the fix would be converting the file to TS.

---

Okay, so I think the issue started from #85 when I removed @types/testing-library__jest-dom.

The package was added during the Storybook 8 upgrade to resolve some TS errors. I later found that this is an internal package of @testing-library/jest-dom, and we aren't supposed so consume it directly as @testing-library/jest-dom already includes type definitions, so I removed the types package.

Upon removing the package, the editor showed me a lot of TS errors in test files because apparently TS couldn't find the type definitions for the matchers. Upgrading @testing-library/jest-dom resolved the issue for me (we didn't have typecheck run on test files, so the tsc command didn't error out).

With typecheck being enabled on all TS files, the errors re-surfaced (my editor didn't have any errors, but tsc was clearly not happy).

There are a bunch of similar issues on the @testing-library/jest-dom repo:

• Property 'toBeChecked' does not exist on type 'Matchers<void, Element>' testing-library/jest-dom#442
• Property 'toBeInTheDocument' does not exist on type 'JestMatchers<HTMLElement>' testing-library/jest-dom#546
• Property 'toBeInTheDocument, toBeDisabled, etc' does not exist on type 'JestMatchers<HTMLElement>'  testing-library/jest-dom#571

#442 has a lot of details, and here is the summary:

• The way the package exposes type definitions appears to be unconventional, and TypeScript couldn't pull the types out
• Some workarounds are:
  • Installing @types/testing-library__jest-dom
  • Adding import '@testing-library/jest-dom/extend-expect' to the jest setup file
    • This is only relevant to v5, we are on v6 now after chore(deps): remove @types/testing-library__jest-dom and upgrade @testing-library/jest-dom #85.
  • Specifying the types packages in tsconfig.json, via the types option
    • Worked, but having to explicitly list out type packages is odd and adds too much overhead. Here is the commit: 11fecd4 (#97).
• pnpm doesn't hoist @types packages by default. The fix is to create a .npmrc file and specify public-hoist-pattern.
  • There is a note from the public-hoist-pattern doc: "This setting is useful when dealing with some flawed pluggable tools that don't resolve dependencies properly."
  • The public-hoist-pattern change seemed to work for some people, but not for me.
  • I found this pnpm behavior interesting but didn't spend much time on it, as I don't think we should mess with the pnpm settings just to get a weird package to work.

That was it from the issue thread. And it took me a looong while to come up with a theory:

• @testing-library/jest-dom contains the type definitions
• The only place that imports @testing-library/jest-dom is jest.setup.js
• Since jest.setup.js is a JS file, tsc ignores it and thus doesn't pull out the types it needs

The next thing I did was converting jest.setup.js and jest.config.js to TS. However, the test command didn't work because Jest requires ts-node, which we recently swapped for tsx. This is why I had to add ts-node back in and remove tsx.

[huyenltnguyen]

cc'ing @ojeytonwilliams since I'm undoing your changes here 😄

[ojeytonwilliams]

Impressive detective work, @huyenltnguyen! Thanks for the detailed write-up.

Based on your investigations I found another workaround: add allowJs: true to the tsconfig. That way, jest-setup.js's type imports get compiled and TS is happy.

My only concern with the approach in this PR is ts-node, because it's a pain when trying to use ESM. However, we can either use allowJs or simply use ts-node for jest and tsx to run scripts.

Anyways, none of that matter for this PR!

LGTM 👍

[huyenltnguyen]

because it's a pain when trying to use ESM

Oh, TIL. I wasn't aware that ts-node doesn't work well with ESM 😅 I can create a PR to add tsx back.