[Bug] TS2742: The inferred type of 'testContext' cannot be named without a reference to './.yarn/cache/...'

[skoging]

• I'd be willing to implement a fix

Describe the bug

Typescript infers types with a relative path to the cache, instead of a dependency name.

Yarn 2: ./.yarn/cache/@types-react-npm-16.9.19-21809ae185-1.zip/node_modules/@types/react
Yarn 1: react

To Reproduce

Example file: https://gist.github.com/skoging/72262b3ac553899b61ad7b6844b3b2b3

yarn init -y
yarn policies set-version (1|2)
yarn add react @types/react typescript@3.7.5
yarn tsc --lib es6 -d a.ts

Yarn 1 succeeds, while Yarn 2 produces the following error:

a.ts:3:14 - error TS2742: The inferred type of 'testContext' cannot be named without a reference to './.yarn/cache/@types-react-npm-16.9.19-21809ae185-1.zip/node_modules/@types/react'. This is likely not portable. A type annotation is necessary.

3 export const testContext = createContext(0);
              ~~~~~~~~~~~


Found 1 error.

Screenshots

If applicable, add screenshots to help explain your problem.

Environment if relevant (please complete the following information):

• OS: Windows and Ubuntu
• Node version 13.2.0
• Yarn version 2

Additional context

Probably a duplicate of #227, but that issue seems to have been closed by the author when he found a workaround. The problem is still present.

Not sure if this is a problem with typescript itself or the yarn berry typescript compatibility patch.

Issue in TypeScript repo: microsoft/TypeScript#36675

[skoging]

To see the output causing the issue clearly, changing the file extension to .js and compiling with the --allowJs flag on:

yarn tsc --lib es6 -d --allowJs a.js

Will produce the following output:

// a.d.ts
export const testContext: import("./.yarn/cache/@types-react-npm-16.9.19-21809ae185-1.zip/node_modules/@types/react").Context<number>;

TypeScript doesn't appear to error on this in declarations inferred from js files, and instead produces an output with the inferred import. This is likely due to inferring declarations from js files being a new 3.7 feature, but it does show clearly why this output is incorrect.

While Yarn 1 will correctly output:

// a.d.ts
export const testContext: import("react").Context<number>;

[arcanis]

The resolution looks correct (the path is properly resolved), so I'd tend to think the problem is on the TS side. If I remember correctly the last time I investigated this I noticed that TypeScript was doing something akin to path.startsWith('node_modules/') && path.count('node_modules') == 1 to check whether the path is located at the root of the project, which doesn't work in our case (since it's in ./.yarn/cache/<archive>/node_modules/<name>).

We even had this problem ourselves, cf #736 (comment). Honestly I don't have enough knowledge in the TypeScript internals to be 100% sure of what I'm saying, so I think it would be worth opening up an issue on their tracker at least to be sure we're not missing something (the heuristic they use looks weird, because it seems like to wouldn't be able to detect hoisted references ...).

[yarnbot]

Hi! 👋

This issue looks stale, and doesn't feature the reproducible label - which implies that you didn't provide a working reproduction using Sherlock. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we're a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolution faster). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it's a Windows-only issue), a maintainer will have to manually add the upholded label.