chore: remove @types from dependencies

[wallzero]

Fix #427

What:

Type definitions should be under devDepedencies

Why:

Types are not runtime dependencies. It is also easier for downstream projects to manage types.

How:

Moved @types/testing-library__jest-dom from dependencies to devDepedencies in package.json.

Checklist:

• Documentation
• Tests
• Updated Type Definitions
• Ready to be merged
  

[nickserv]

We intentionally bundle the types so they don't have to be installed separately with npm. I'd also argue having these types in devDependencies is incorrect, since the types are used when Jest DOM is installed, not when it's in development.

[codecov]

Codecov Report

Merging #472 (3bc2a60) into main (948d90f) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main      #472   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           26        26           
  Lines          630       630           
  Branches       236       236           
=========================================
  Hits           630       630           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[nickserv]

I've changed my mind. I think we should just uninstall the @types package completely to fix Vitest and TypeScript support (#427). We're not using it in development anyway.

Note that I'm intentionally suggesting this as a breaking change, as it's important for accommodating Vitest and TypeScript users. Jest users would need to install this package, and we should document that before publishing a major release. I'd like another maintainer to approve this before merging ideally.

Alternatively, we could just drop the dependency on Jest in the types package, or do that as we move types into this package.

[EzraBrooks]

Any idea when this change will be merged? This would be very helpful for me, as I'd like to drop @types/jest in favor of @jest/globals in my project but cannot because of this transitive dependency that extends the global namespace.

[kentcdodds]

Vitest (is fantastic and) has made this challenging. I wonder whether there's an established pattern for supporting both since the matchers API in vitest is forked from Jest. I definitely feel like this needs to be solved.

Unfortunately I don't have bandwidth to work on this myself so I'm not going to merge this and put that burden on someone else, but I wanted to come in here and voice my support for doing something about this problem.

[kentcdodds]

Oh, and personally, I'm actually ok with this change (of course, it would be breaking). It's more in line with the way most packages work with definitely typed anyway 🤷‍♂️

But it would be nice if there was a way to make the types themselves support both vitest and jest at the same time. I have no idea whether that's possible.

[jgoz]

@kentcdodds

But it would be nice if there was a way to make the types themselves support both vitest and jest at the same time. I have no idea whether that's possible.

#511

[github-actions]

🎉 This issue has been resolved in version 6.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀