[core] Lock jsdom version

[cherniavskii]

After merging #11303 I noticed that our CI pipeline became slower:

The difference is coming from the test:unit step:

Before	After

Turns out, there was a CSS selector engine change in jsdom that causes a performance regression - see https://github.com/jsdom/jsdom/releases/tag/23.2.0

I've locked the jsdom version for now.

[mui-bot]

Deploy preview: https://deploy-preview-11652--material-ui-x.netlify.app/

Generated by 🚫 dangerJS against 62e6481

[cherniavskii]

Also, there's something wrong with our setup - the Core repo runs twice the number of tests in less time:

MUI Core	MUI X
https://app.circleci.com/pipelines/github/mui/material-ui/117981/workflows/b936303c-3036-444d-822f-84332cbf33e4/jobs/634081	https://app.circleci.com/pipelines/github/mui/mui-x/50422/workflows/87beaa90-020b-45a9-83fa-31fde02ea708/jobs/289067

[LukasTy]

Nice observation! 💙
Do you know if renovate won't try bumping a direct dep version? 🤔

Also, there's something wrong with our setup - the Core repo runs twice the number of tests in less time

I'd say that in this case we are trying to compare apples to oranges.
The components in core repo are way lighter, easier and thus faster to render, don;t you think? 🤔

[cherniavskii]

Do you know if renovate won't try bumping a direct dep version? 🤔

Good point, I think it would try bumping the version according to https://docs.renovatebot.com/getting-started/use-cases/#package-managers-with-lock-files
I'll address this 👍🏻

[cherniavskii]

The components in core repo are way lighter, easier and thus faster to render, don;t you think? 🤔

You're right 👍🏻 I thought this could be a reason that explains why tests in jsdom are slower than tests in real browsers, but it's not 🙃

So the question remains - how come tests in jsdom are slower that tests in real browser? The whole point of jsdom is that it is supposed to be a "lightweight browser" that runs tests faster 😅

[LukasTy]

So the question remains - how come tests in jsdom are slower that tests in real browser? The whole point of jsdom is that it is supposed to be a "lightweight browser" that runs tests faster 😅

Well, that is a good question indeed. 💡
Maybe it could be due to how we write tests - AFAIK, preferring accessible getters (mostly getByRole) is way slower than just getByText or especially getByTestId.
Should it be slower than an actual headless browser? 🤔 Hell no, that doesn't make sense... In such a case, it's better to write as few unit tests and as many "e2e" tests run in a browser. 🤷

[flaviendelangle]

So the question remains - how come tests in jsdom are slower that tests in real browser? The whole point of jsdom is that it is supposed to be a "lightweight browser" that runs tests faster

My hypothesis is that JSDoc is a lot lighter to get running, so the simplest test will be waaaaaay faster.
But it does not have all the complex optimization of a real browser so when the DOM structure becomes more complex and the selectors more advanced it looses ground.

I don't have any numbers to back it up though