Update Vitest to 1.6.0

[HiDeoo]

This PR is targetting #1846.

Description

This PR updates the Vitest version used in the monorepo to the latest version instead of the initial 1.4.0 bump due to a test failure.

Why was this test failing when upgrading to at least Vitest 1.5.0?

• Vitest 1.5.0 introduced a change to the workspace feature current working directory (cwd) making it the config directory.
  • Using version 1.4.0, the current working directory would be packages/starlight/
  • Using version 1.5.0, the current working directory would be packages/starlight/__tests__/i18n-non-root-single-locale/ for the i18n-non-root-single-locale test suite.
• Our tests use getViteConfig() which will internally call resolveConfig() which calls resolveRoot() with an undefined argument which would end up using process.cwd().
• With Astro now using packages/starlight/__tests__/i18n-non-root-single-locale/ as the root, packages/starlight/__tests__/i18n-non-root-single-locale/src/content/i18n/fr.json would be automatically loaded when we call getCollection() which was not the case before.

Why is only the i18n-non-root-single-locale test suite failing and not the i18n test suite which uses a similar setup?

• The i18n test suite is not impacted because the default locale is en but is configured with a lang using a regional subtag (en-US) which means the user config overrides needs to be in for en-US and thus not being impacted by en.json being loaded.

How is this PR fixing the issue?

• This PR updates the i18n-non-root-single-locale test suite to use the fr-CA for the lang of the default locale to use the same setup as the i18n test suite.

What alternatives were considered?

• Using Astro 4.8.0 getViteConfig() new second argument to specify the root in the inline Astro config to fallback to the previous behavior and avoid using process.cwd() but I think this is wrong to just assume the CWD is not the root of the test suite.
• Moving out the packages/starlight/__tests__/i18n-non-root-single-locale/translations-fs.test.ts to another dedicated suite (where we do not mix real CC files and CC mocking). I think this is a valid one but we would need I think to do the same for the i18n test suite which is not failing. I think it's better to have a consistent setup for all the test suites but I'm open to feedback on this.

Why are the .gitignore changes in this PR required?

By Astro now using the proper root, and getViteConfig() somehow triggering someting close to astro sync, we end up with all the extra files in each test suites instead of just packages/starlight/ like before when this folder was considered the CWD.

[changeset-bot]

⚠️ No Changeset found

Latest commit: c01496a

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
starlight	✅ Ready (Inspect)	Visit Preview	May 15, 2024 11:00am

[delucis]

Amazingly thorough investigation and documentation of the fix @HiDeoo! This all makes sense to me and I’m happy to go with this approach as you suggested.

One question: do you think it makes most sense to merge this into the MDX v3 branch or is it better to target main and then I can rebase the MDX v3 branch on top of these changes?

[HiDeoo]

One question: do you think it makes most sense to merge this into the MDX v3 branch or is it better to target main and then I can rebase the MDX v3 branch on top of these changes?

I initially targeted the MDX v3 branch as it's the one that needed the Vitest update (due to Vite 5.1 changes with the Astro bump) but technically, I guess this could also makes sense to target main as it kinda ends up being an unrelated issue 👍 Up to you, I'm fine with either way, let me know if you want me to update it so that it can target main.

[delucis]

Let's target main then if you have time to do that — helps us avoid bundling up too many changes in one PR. Thank you!

[HiDeoo]

This should be good, also pushed an empty commits to re-run all the workflows as I think there is still no event so that the workflows can be triggered after the base branch change.

[delucis]

LGTM! Thanks for cleaning that up @HiDeoo 🚀