-
Notifications
You must be signed in to change notification settings - Fork 509
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: Why not include @types/jest as TSDX's dependencies? #633
Comments
Please don’t bloat dependencies, it requires maintaining, updating and time to download/install for every deploy |
TSDX's dependencies include When I generate a new project using TSDX, I get The version is a mismatch, this is not a problem about bloat dependencies. |
I don't know for sure, but I'm pretty sure the reason for that is historical rather than intentional. TSDX was originally written in JS and most of the tests are still in JS (I've got a TODO to rewrite them, hopefully won't be too hard -- EDIT: it wasn't, see #649).
Also seems like PR welcome to change both/either of those. Might need to be careful with the
Side note: We're able to get away with most types as devDeps because TSDX is a CLI and so not generally imported into any TS code |
@allcontributors please add @rockmandash for bug |
I've put up a pull request to add @rockmandash! 🎉 |
If you're working with Karma on a project ( I like (I also have projects with jest, so those are fine) |
Current Behavior
@types/jest
is in newly generated package's devDependencies.Desired Behavior
Why not include
@types/jest
as TSDX's dependencies?This way, the newly generated boilerplate package's devDependencis will be cleaner.
Suggested Solution
Actually, if the newly generated boilerplate package's devDependencis includes only TSDX, that will be awesome, and I think it's doable.
Who does this impact? Who is this for?
All users
Describe alternatives you've considered
None.
The text was updated successfully, but these errors were encountered: