TypeScript: Conflicts between typings exposed globally

TypeScript Version: 2.7.0-dev.201xxxxx

Search Terms: cypress; beforeEach; global conflict; duplicate identifier

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

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.

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 50
Comments: 24 (5 by maintainers)

Most upvoted comments

@mhegazy Can you please reconsider?

+17

danielkcz on Aug 1, 2018

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.

danieldelcore on Apr 15, 2020

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

leoyli on May 17, 2019

@FredyC found an interesting solution though - here https://github.com/nrwl/nx/issues/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.

hypeofpipe on Apr 29, 2019

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

--traceResolution

kitsonk on Aug 26, 2018

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.

danielkcz on Jul 21, 2018

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

danielkcz on Jul 20, 2018