Closed
Description
The goal of having @types/ in our dependencies is so that users don't have to manually add them.
This has four downsides:
- Assuming best case scenario where
@types/testing-library__domis up-to-date:@testing-library/domgets an update. Weyarn upgrade @testing-library/dom.@types/testing_library__domis not automatically updated because of lockfiles. Same issue withyarn add @testing-library@the-new-version-release - To get an update, downstream consumers either have to nuke their lockfile (bad) or manually bump them. Automatic solutions like renovate or dependabot do not update transitive dependencies but only top-level ones. This means
@types/testing_libray__domwon't get automatic updates. - On a major we have to do a lot of manual maintenance to get types to downstream packages: Release major, Update types, update
@types/testing-library__domin our packages.json (fix: Bump types dom-testing-library#495) - We depend on
@types/testing-library__domtwice: Once by depending on@testing-library/dom->@types/testing-library__domand by depending on@types/testing-library__react->@types/testing-library__dom. This could result in two different versions of@types/testing-library__dom. Can be resolved by nuking lockfile ornpx yarn-deduplicate.
All of these issues can be resolved manually but require a lot more knowledge than "add @types/testing-library__react to your dev-dependencies" which is already the standard in the ecosystem.
I propose we get rid of the entry and advise users to manually add it. This is a lot easier since it's what typescript users are already used to (adding @types/ to devDependencies) vs requiring to maintain their lockfile.
This is a breaking change for type consumers. Type related breaking changes are a lot less severe since every type related change is a breaking change