Vitest Docs Updates

Clear and concise description of the problem

As discussed in Discord, I feel like there may be some places for improvement to the Vitest docs to improve their clarity and consistency. Thoughts are below:

Suggested solution

Overall Docs Principles

• Be Self-Contained - While there are a number of existing tools Vitest pulls in or works like (Chai, Jest, etc…), whenever something is important enough to include in documentation, descriptions and usage examples should be included in the docs instead of linked to an outside source. This will help keep users focused on their task at hand without jumping between multiple tabs to understand a single concept.
• Ensure Consistent Code Samples - All code samples should use the same paradigm (expect or assert, describe/it or test, etc…), and no code samples use global configuration (this means samples should include the correct import statements for what's needed, too).
• Always Include Code Samples - All methods and APIs (like beforeEach), should include commented code samples showing how to use them, not just prose documentation
• Anticipate Questions with Answers - There are a number of places where user questions can be anticipated and preemptively answered, like "how can I use a Chai module" when Chai is built in is mentioned. Ideally, the answers to these questions should be called out in an offset display (like a message box) to separate them from the rest of the documentation.
• Version Features - Include what version of Vitest is needed for a particular feature, like 11ty, to make it possible to debug why a feature may not be available.

Information Architecture and Content Strategy

• Stronger Guide/API Separation - Readers should be able to anticipate the type of documentation they'll get from each section, and right now what's in Guide and what's in API are very similar. I'd recommend Guide being more long-form explanatory content that is usecase focused, possibly without covering every method, and API being focused on ensuring every user-facing method or interface is explained. Guides should link to methods.
• Sections should be Hierarchical and Self-Contained - High-level sections (like mocking, testing, grouping, etc…) should have their own high-level subnav in each section, and that should be self-contained with an introduction explaining the topic, and only assuming a user will go to that introduction to learn more. The current mocking docs, for example, introduce vi in features->mocking so if you dive straight into those guides you don't know where vi comes from. Generally, this also means reducing the documentation in "features" and expanding it into other places in the guide
• URLs are the "REST API" for Docs - URLs, and thus page structure, should be treated like requesting resources from a REST API, including clean URLs instead of .html extensions. This parallels well with hierarchical; so /guide/mocking would be the mocking landing page, /guide/mocking/timers would be the page for timer mocking, etc…. This will likely encourage a knock-on effect of wanting section nav/breadcrumbs and possibly breaking long pages into shorter onces.

Alternative

No response

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Start by reviewing the linked Vitest guide and comparing the current Guide, API, and features sections, especially mocking. Define a smaller, concrete documentation scope before editing; done should mean the agreed section structure, examples, navigation, and version notes are consistently updated.