Property 'element' does not exist on type 'ExpectStatic'

[Pinakin-Desai-HBK]

Describe the bug

Installed the latest vitest (2.1.5) but getting the following error - Property 'element' does not exist on type 'ExpectStatic'.

This was reported previously but seemed to have been fixed - #4273

Test:

package.json:

vitest:

Reproduction

Install the latest vitest and try to access the element property of expect.

System Info

vitest 2.1.5

Used Package Manager

npm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[github-actions]

Hello @Pinakin-Desai-HBK. Please provide a minimal reproduction using a GitHub repository or StackBlitz (you can also use examples). Issues marked with needs reproduction will be closed if they have no activity within 3 days.

[Pinakin-Desai-HBK]

Here is a minimal reproduction - https://stackblitz.com/edit/vitejs-vite-vnkaxo?file=package.json,src%2Fassets%2FApp.test.tsx&terminal=dev

[kossnocorp]

Importing the matchers.d.ts directly in the test file helps, but it would be great to have a fix:

import "@vitest/browser/matchers.d.ts";

// Your tests...

[hi-ogawa]

Adding manually dts is necessary since expect.element is only available on browser mode. Closing as this is in the doc https://vitest.dev/guide/browser/assertion-api.html and we'll soon improve it better #6934

[Smrtnyk]

@hi-ogawa
I am not a typescript expert, but just an idea.
Would it be possible to have a special expect that could be imported from @vitest/browser that would already have this automatically typed?

[kossnocorp]

I think it would be safe to include both the type and the dummy matcher that would throw an error if it's not the browser environment in the global expect, or, as suggested, have a separate browser expect/browserExpect. It will be great for discoverability and improve the DX.

[hi-ogawa]

I think it would be safe to include both the type and the dummy matcher that would throw an error if it's not the browser environment in the global expect

Yeah, that might work, but I guess there are a few concerns:

• @vitest/browser/matchers might pollute too much (e.g. IDE auto-completion) as it includes jest-dom assertions too
• there's still provider specific extension for @vitest/browser/matchers/providers/xxx

[Pinakin-Desai-HBK]

Adding manually dts is necessary since expect.element is only available on browser mode. Closing as this is in the doc https://vitest.dev/guide/browser/assertion-api.html and we'll soon improve it better #6934

I don't see where it says to add it manually in that link.

[Pinakin-Desai-HBK]

import "@vitest/browser/matchers.d.ts";

Thanks. This works too:

import "@vitest/browser/matchers";

[hi-ogawa]

I don't see where it says to add it manually in that link.

@Pinakin-Desai-HBK I'm referring to the first paragraph in the doc. There are actually many ways to help tsc and the doc mentions that compilerOptions.options in tsconfig.json:

If you are using TypeScript or want to have correct type hints in expect, make sure you have either @vitest/browser/providers/playwright or @vitest/browser/providers/webdriverio specified in your tsconfig depending on the provider you use. If you use the default preview provider, you can specify @vitest/browser/matchers instead.