[code-infra] Package test utils

[michaldudak]

Renames the @mui-internal/test-utils to @mui/internal-test-utils and prepares the package to be published to npm.

[mui-bot]

Netlify deploy preview

https://deploy-preview-41177--material-ui.netlify.app/

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 21c6da3

[Janpot]

Do we need to find more consensus cross team before fully committing to nx as a build tool?

[michaldudak]

Isn't it just a Core repo problem? If other repos use built packages from npm, we can still rely on pnpm. Or is there something more in the other repos that could benefit from a more advanced orchestrator?

[Janpot]

I'm just mentioning because I remember this coming up before with the X team in https://www.notion.so/mui-org/code-infra-Introduce-align-on-a-task-runner-ee2765d98ae74ec2bf9dca9b88a3561a#4356019bcc8e4900849fa1156eb7630d
The only thing I want to avoid is X and core using a different one.

[Janpot]

Is running nx through pnpm necessary here? In some commands it's running like this, In some other commands nx is run directly

Suggested change

	"test:karma": "pnpm nx run nx_test_karma",
	"test:karma": "nx run nx_test_karma",

[michaldudak]

👍 nx run is sufficient indeed.

[Janpot]

Looks good, hope I didn't miss anything scrolling through those renames 🙂
I added one question, no blocker.
After we merge this, I suppose we'd do the same for @mui-internal/api-docs-builder?

[michaldudak]

Yes, the API docs builder is next. It can be included in @mui/internal-scripts.

[DiegoAndai]

@michaldudak thanks for this! Question: Previously, I was running unit tests with the --watch flag (pnpm test:unit --watch) to watch file changes. After this update, the --watch flag seems to be bugged: It does rerun tests after file changes, but the file changes are not taken into account. Is this expected? Is there a new way to watch changes?

[michaldudak]

I'm not aware of anything that could cause such an issue. I'll investigate.

[michaldudak]

One issue I found (and fixed): #42519
Let me know if it helps.

[DiegoAndai]

I tested again both on your PR and the next branch, and --watch is working as expected on both 😅
I'm not sure what happened the other day.
Thanks!

[oliviertassinari]

I have found a regression from this PR in HEAD, while I was trying to run a test. It crashes now:

1. Start from a clean state, git rm -rf . && git clean -fxd && git reset --hard && pnpm i
2. Run pnpm tc useControlled

vs. the commit just before:

@DiegoAndai I almost never use pnpm test:unit --watch because I find it way too slow to run, especially when I switch between 20 PRs a day.

A side observation: I might sound like a broken record, but I'm still unable to see the net benefit of building the dependencies of test utils internal in http://github.com/mui/material-ui vs. consuming straight from the source. For a Pigment CSS dependency written in Rust, yes, OK: a higher fidelity npm publish experience feels more valuable, especially if nothing else downstream uses Rust.
But here it feels like we trade a slower test DX (on HEAD, it in my test, it took 10.13s to run on cache miss and 6.89s on cache hit vs. on 384e5e4 it took 4.49s for pnpm tc useControlled to run, no cache) and a more complex build setup (have to care about caching and correct build interdependencies vs. we have to pay the cost of build fidelity in any cases for the public packages since it would be an impossible DX for maintainers/contributors to build them for each change to try them on the docs or tests) in exchange for a higher fidelity npm publish experience.

Opened #42572 to restore HEAD in a working state.

[michaldudak]

I'm still unable to see the net benefit of building the dependencies of test utils internal in http://github.com/mui/material-ui vs. consuming straight from the source.

This ensures that the code in this repo uses the same implementation of test-utils as other repos (for example making sure it doesn't use something that's not exported in the release build).
The test-utils (as the rest of the shared infra code should be moved out of this repo and referenced through npm by Material UI. This will make it even faster than the implementation before this PR (no need to transpile TS anymore).