[Bug?]: `@types` packages installed in a subpackage are not correctly removed when later changes cause them to be hoisted to the root

[seansfkelley]

Self-service

• [ ] I'd be willing to implement a fix

Describe the bug

I've had this bug happen in two situations. The first one is more unusual, but it was the first one I found and as such is more detailed. The second scenario happened more recently but I've only provided basic details because I believe the root cause is the same.

First (and more detailed) scenario

I had some @types/ packages that in Yarn 1 were nohoisted to make the build happy. In upgrading to Yarn 3, they are no longer hoisted and the build was fixed so this is not a problem. However, some other devs were pulling these changes and hitting spurious typechecking failures, which I eventually traced to Yarn not removing these now-unused nohoisted @types/ packages, which were causing the Typescript compiler to pick up out-of-date typings.

It seems yarn install in v3 is not as strict as its v1 equivalent (where this issue does not reproduce).

Second (and more routine) scenario

My project used to depend on multiple versions of @types/react-router-dom. As such, that dependency was pushed into the several packages which depended on it. Recently that was upgraded and all packages now agree on the version, so the @types were hoisted. However, the non-hoisted dependencies were left lying around, leading to the same miscompilation issues noted above.

To reproduce

I wasn't able to get Sherlock to repro -- it seems it does not support yarn set version.

I made a repo with copy-pastable instructions: https://github.com/seansfkelley/yarn-hoisting-bug

Environment

System:
   OS: macOS 10.15.7
   CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
 Binaries:
   Node: 14.17.3 - /private/var/folders/fn/ltn38fwn2x70zt_8w41h0f9w0000gn/T/xfs-98af1c40/node
   Yarn: 3.0.2 - /private/var/folders/fn/ltn38fwn2x70zt_8w41h0f9w0000gn/T/xfs-98af1c40/yarn
   npm: 6.14.13 - ~/.volta/tools/image/node/14.17.3/bin/npm

Additional context

No response

[seansfkelley]

I found another situation in which this happens. I've updated the title and description, but not the repro, as I'm already several yaks deep at the moment and it appears the root cause is the same.

[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 resolutions). 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. Thanks for helping us triaging our repository! 🌟

[seansfkelley]

This is still a bug, and unfortunately I don't have a compelling automated repro short of dumping random files in node_modules, which isn't really representative of the problem.

[larixer]

Reproduction repository is no longer available.