Conflicts between typings exposed globally

[danielkcz]

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 @types packages 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 skipLibCheck because 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.

"types": ["node", "react", "jest", "debug", "googlemaps", "markerclustererplus"],

Possible solution
I think it might be worth to expand configuration of types to have a include/exclude variant. That way I could exclude mocha typings 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 root tsconfig a include mocha there instead.

[mhegazy]

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.

[danielkcz]

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?

1. Two different test frameworks, not really possible to force either one of them to use exact same type as other
2. 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
3. I cannot imagine how that would work and it feels a rather weird coupling together two different test frameworks.

[mhegazy]

I think it might be worth to expand configuration of types to have a include/exclude variant.

you already have types which is a list. i do not expect the list of your @types package to be that large, that you can not enumerate them all modulo mocha in the "types" property in your tsconfig.json.

[danielkcz]

@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?

[mhegazy]

I 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 mocha and jest.

[danielkcz]

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 types config field can accept either array or object with include/exclude properties. For most people who are not solving this issue, it won't matter that this option is in there.

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

[danielkcz]

@mhegazy Can you please reconsider?

[kelly-tock]

@FredyC did you end up with a workaround?

[danielkcz]

@kelly-tock The workaround is obvious since there is no exclude option, you have to do the opposite.

@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?

[RyanCavanaugh]

@FredyC The issue isn't locked. Maintainers are still reading the issue tracker.

[danielkcz]

@RyanCavanaugh I know it's not locked issue, but closed ones don't get much of the attention either :(

[JulianG]

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?

[kitsonk]

Any suggestions on how to find the list of types my project is using?

--traceResolution

[hypeofpipe]

Is there is any update? Issuing the same problem

[danielkcz]

I am afraid until this stays closed, it will never get any attention despite what @RyanCavanaugh said before.

[hypeofpipe]

@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.

[danielkcz]

Feels kinda far fetched. I've opted for a much simple solution and have a cypress folder with its own package.json and yarn.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 :)

[leoyli]

@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 @types file 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.

[MrStLouis]

@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 🙏

[danieldelcore]

I think what would really help in this case is to at least have the ability to turn off module @type declarations 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 @type dependency 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.

[gamegee]

Is there any update ?
I am issuing the same problem for KeyboardEvent type.
The global name is conflicting with @types/react and DOM types (from typescript)

[aleclarson]

An open issue related to this can be found at #37053. Show your support with upvotes and comments.

[matthew-dean]

@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. 🤷‍♂️