-
-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[core] Migrate test runner to vitest #71
base: master
Are you sure you want to change the base?
Conversation
What's the motivation for this change? |
For historic reasons Toolpad ended up using pros:
cons:
|
How do we run the tests in a real browser with vitest? As I understand things:
Now https://github.com/emotion-js/emotion/, https://github.com/callstack/linaria/, https://github.com/styled-components/styled-components/, seem to run tests with jest (and maybe jsdom) only. https://vitest.dev/guide/browser.html + https://vitest.dev/guide/improving-performance.html, oh maybe could solve two pain points 🤔
We should transpile the source to be close to production, but I guess this won't be an issue.
We should be able to reproduce equivalent utils. |
Yep, they're adding a browser mode. Granted, it's not declared stable yet, but I made it work today in Toolpad in relatively short time. It was that or move to mocha+karma. I gave it a quick shot, and it's quite delightful, still not supporting the full functionality of the node.js runner, but certainly seems to be usable for us.
vitest transpiles the code for you, with vite. It's a trade-off I'm personally willing to make. I think it could make sense to try and cover this use-case with a few integration tests instead. Fewer tests, but closer to actual production code. |
Would moving to vite instead of babel be a huge issue? We have some complex babel transpiling in X that I'm not sure would be portable to vite. |
Which transformations do you think aren't portable? The one I'm aware of is the macro in MUI core for error messages. I don't think X is even making use of that? In any case, I don't think there is anything preventing us from using a babel transform in vite if necessary. But I'd love to get rid of the macro system altogether if we can, making our code portable to other compilers would be a big win. IMO transforming the test format from mocha+chai to vitest will probably be the most intensive part of the process. |
Oh, I was mostly asking if there are known issues, I don't have a lot of exp with vite/vitest. But I would guess on X the date adapters import replacement could be an issue. |
😄 Actually mentioning this exact use-case in my comment above.
I expect that we can build that on top of vitest module mocking. I'm not a huge fan of this method as it's quite a lot of magic, but it should be much more straightforward to do from DX point of view. 🤷 As long as we're not starting to overuse this feature everywhere. |
Note that the class names for the generated css have changed because earlier, the root directory was considered from repo root, but now, it considers the package directory as the root. And classname generation depends on this path.