Repository navigation
Conflicts between typings exposed globally #22331
Description
Activity
The issue here is caused by the declaration files defining the same global functions. this can be remedied by either 1. both defining them the same exact type, 2. refactoring the declaration files to be modules instead of global declarations, or 3. by refactoring the declaration files to have a third common package both packages depend on and have the shared declarations.
Hey, so you say this not something that can be fixed on TypeScript side? And what about my suggestion? Seeing a number of thumbs here I would say I am not the only one bothered by this. Why forcing the solution to the userland when there is such an easy fix?
- Two different test frameworks, not really possible to force either one of them to use exact same type as other
- I am not sure it can work in this case since there are global functions and you don't generally want to have imports in your tests
- I cannot imagine how that would work and it feels a rather weird coupling together two different test frameworks.
I think it might be worth to expand configuration of types to have a include/exclude variant.
you already have
typeswhich is a list. i do not expect the list of your@typespackage to be that large, that you can not enumerate them all modulo mocha in the"types"property in your tsconfig.json.Mohamed Hegazy (@mhegazy) Well, it certainly is possible but is it a good DX? I mean why not give another option that makes things easier and does not break anything?
Reacted by Daniel Del CoreI am not arguing there is value. The question is the cost of adding a new feature both in terms of complexity to new users, and in terms of maintenance cost vs the value added. I would argue the real issue is the declaration of
mochaandjest.They are both testing frameworks relying on globals (sadly) with same-named (mostly standardized) variable names. It's not really something that can be changed without a breaking change.
The complexity you mention is optional, the
typesconfig field can accept either array or object withinclude/excludeproperties. For most people who are not solving this issue, it won't matter that this option is in there.Reacted by Cody CasterlineAutomatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.
Mohamed Hegazy (@mhegazy) Can you please reconsider?
Reacted by Jonathan Petitcolas, Sheenan Tenepre, Kelly Milligan, Julian, Dan Delgado, Peter Kieltyka, Anna Kosolapova, Nandin Borjigin, Leo Y. Li, Marcelo Cardoso and 7 moreFredyC did you end up with a workaround?
Kelly Milligan (@kelly-tock) The workaround is obvious since there is no
excludeoption, you have to do the opposite.Mohamed Hegazy (@mhegazy) I don't understand why is to difficult for you to even talk about it. You did admit there is some value in it, so why to cut off discussion suddenly?
FredyC The issue isn't locked. Maintainers are still reading the issue tracker.
Ryan Cavanaugh (@RyanCavanaugh) I know it's not locked issue, but closed ones don't get much of the attention either :(
I have the same problem, and I don't even know which types to list in my tsconfig.json.
I was already listing "chrome" because I'm using some chrome APIs.
Any suggestions on how to find the list of types my project is using?Any suggestions on how to find the list of types my project is using?
--traceResolutionReacted by JulianIs there is any update? Issuing the same problem
I am afraid until this stays closed, it will never get any attention despite what Ryan Cavanaugh (@RyanCavanaugh) said before.
FredyC found an interesting solution though - here nrwl/nx#816
@/FrozenPandaz What about the workaround of adding import 'jest'; to test-setup.ts? I seems to do the job and I haven't seen any side effects.Reacted by Zac St LouisFeels kinda far fetched. I've opted for a much simple solution and have a
cypressfolder with its ownpackage.jsonandyarn.lock. That way dependencies don't collide as long as I don't need Jest when writing cypress tests which does not make much sense :)FredyC, +1. I was bothered by the type conflicts here... It's really annoying you can have only white list but have no black list. The black list feature is helpful for mono-repo to have their
@typesfile properly mange at the root level.Plz, reconsider to add this support since we have white list, logically it should not be too difficult to black list, I might be wrong though.
Reacted by gama410, Daniel Del Core, Simon.b, Michael Vasin and Andrii OriekhovVolodymyr V. (@hypeofpipe) I wish I had found your comment a week ago. These type collisions have been murdering my productivity and now I can finally publish 🙏
I think what would really help in this case is to at least have the ability to turn off module
@typedeclarations when they do clash.For example:
Root tsconfig.json
{ "paths": { "mocha": ["typings/mocha.d.ts"] } }typings/mocha.ts
declare module 'mocha';
We're really at the mercy of library authors to avoid using globals, but without another way for projects like Jest to somehow isolate their globals or for users to intelligently turn them off, we're left with having to explicitly define each and every
@typedependency in our tsconifg.
Which is kind of unfortunate solution because you can think types are enabled for a project but they actually won't be unless you remember to add them to the config.Reacted by Michael Vasin, Fahry and Joshua GrunikReacted by Joshua GrunikReacted by Fahry and Joshua GrunikIs there any update ?
I am issuing the same problem forKeyboardEventtype.
The global name is conflicting with@types/reactand DOM types (from typescript)An open issue related to this can be found at #37053. Show your support with upvotes and comments.
Alec Larson (@aleclarson) That issue seems related to particular file types? My issue is that two libraries define global types for
$: jQuery (via DefinitelyTyped) and Vue Macros. Vue Macros type definition seems to "win" in my environment and I can't figure out how to get it to not when except doing a PNPM patch of its package. 🤷♂️
TypeScript Version: 2.7.0-dev.201xxxxx
Search Terms:
cypress; beforeEach; global conflict; duplicate identifier
Code
Reproduction repo
Expected behavior:
To be able to use Cypress and Jest in the same project without explicitly specifying which
@typespackages to use.Actual behavior:
See README in a repo
Related Issues:
cypress-io/cypress#1087
As you can see in a linked issue, there were some workarounds suggested, but I am not happy about any of them. Setting
skipLibCheckbecause of inclusion of a test framework feels mega dirty.Specifying what
@types/*packages to use is not a good DX imo. I already have these listed in my project and I am sure it will grow over time. Worst part is it's not always easy to find which package needs to be included there.Possible solution
I think it might be worth to expand configuration of
typesto have ainclude/excludevariant. That way I could excludemochatypings instead of listing everything I need to include. Also if I would want to write Cypress tests with TypeScript, I would be able to extend roottsconfiga include mocha there instead.