Dependencies on @types/*
requires just as much user attention as not having the dependency
#620
Labels
needs discussion
Whether changes are needed is still undecided and additional discussion is needed.
Uh oh!
There was an error while loading. Please reload this page.
The goal of having
@types/
in our dependencies is so that users don't have to manually add them.This has four downsides:
@types/testing-library__dom
is up-to-date:@testing-library/dom
gets an update. Weyarn upgrade @testing-library/dom
.@types/testing_library__dom
is not automatically updated because of lockfiles. Same issue withyarn add @testing-library@the-new-version-release
@types/testing_libray__dom
won't get automatic updates.@types/testing-library__dom
in our packages.json (fix: Bump types dom-testing-library#495)@types/testing-library__dom
twice: Once by depending on@testing-library/dom
->@types/testing-library__dom
and 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/
todevDependencies
) 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
The text was updated successfully, but these errors were encountered: