[Bug]: typescript patch fails to apply with typescript@4.5

[ezracelli]

Self-service

• I'd be willing to implement a fix

Describe the bug

This is replicable on first install only — on subsequent uninstall/reinstalls of typescript@^4.5.1-rc, the install appears to succeed but the symptoms still persist.

$ yarn add --dev typescript@^4.5.1-rc
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed in 0s 815ms
➤ YN0000: ┌ Fetch step
➤ YN0013: │ typescript@npm:4.5.1-rc can't be found in the cache and will be fetched from the remote registry
➤ YN0013: │ typescript@patch:typescript@npm%3A4.5.1-rc#~builtin<compat/typescript>::version=4.5.1-rc&hash=ddd1e8 can't be found in the cache and will be fetched from the remote registry
➤ YN0013: │ typescript@npm:4.5.1-rc can't be found in the cache and will be fetched from the remote registry
➤ YN0066: │ typescript@patch:typescript@npm%3A4.5.1-rc#~builtin<compat/typescript>::version=4.5.1-rc&hash=ddd1e8: Cannot apply hunk #2
➤ YN0000: └ Completed in 22s 379ms
➤ YN0000: ┌ Link step
➤ YN0000: │ ESM support for PnP uses the experimental loader API and is therefore experimental
➤ YN0000: └ Completed
➤ YN0000: Done with warnings in 23s 511ms

$ yarn tsc --noEmit

[snip]

[snip].ts:3:17 - error TS2307: Cannot find module '[snip]' or its corresponding type declarations.

3 import [snip] from "[snip]";
                      ~~~~~~


Found 24 errors.

To reproduce

$ yarn add --dev typescript@^4.5.1-rc

{
  "devDependencies": {
    "typescript": "^4.5.1-rc",
  }
}

Environment

System:
    OS: macOS 12.0
    CPU: (4) x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
  Binaries:
    Node: 16.12.0 - /private/var/folders/zk/9kgkd8tx4fq9ptvlc7cc8f0c0000gn/T/xfs-59651938/node
    Yarn: 3.1.0 - /private/var/folders/zk/9kgkd8tx4fq9ptvlc7cc8f0c0000gn/T/xfs-59651938/yarn
    npm: 8.1.3 - ~/.npm/bin/npm

Additional context

No response

[Paosder]

This issue occurs in typescript@4.5.2 that causes cannot find module "" in every import statement.

I downgraded typescript to 4.4.4 to workaround this issue.

[sublimator]

It works with the node-modules linker. It must be the new way libs are handled in 4.5

[spa5k]

do they keep changing things every update? I remember that it got broke down in last major update too and needed patch.

[arcanis]

Yes, unfortunately each release seems to touch the resolution in a way that makes the patch incompatible lately ...

[merceyz]

The updated patch was released in 3.2.0-rc.5

yarn set version canary && yarn install

[cBiscuitSurprise]

yarn set version canary did not fix it for me (Windows 19043.1348, WSL 2 Ubuntu)

This worked though (thanks @Paosder):

This issue occurs in typescript@4.5.2 that causes cannot find module "" in every import statement.

I downgraded typescript to 4.4.4 to workaround this issue.

In case someone needs help downgrading:

yarn remove typescript
rm -rf .yarn/sdks/typescript
yarn add typescript@4.4.4
yarn dlx @yarnpkg/sdks base

[merceyz]

yarn set version canary did not fix it for me

@cBiscuitSurprise Did you run an install after changing the Yarn version?

[cBiscuitSurprise]

I did not... But I did just duplicate my working folder and upgraded back to typescript 4.5.2-sdk and it's all working fine... so presumably running yarn install after yarn set version canary would have worked. Sorry for the noise.

[kachkaev]

Running yarn set version canary && yarn install as suggested by @merceyz worked for me! I can now use TS 4.5.2 with PnP in kachkaev/njt#161 🎉

There is a bunch of --experimental-loader warnings after the update, both for node --version v16.13.0 and v17.1.0.

Is there any practical workaround? The warnings are not blocking, they just distract from other (possibly more useful) output.

[merceyz]

Those warnings is showing up after the upgrade because of #3667, I plan on silencing them as they provide no value but for now you can use --no-warnings

NODE_OPTIONS="--no-warnings" yarn lint

[kachkaev]

Great, thanks! I can confirm that NODE_OPTIONS="--no-warnings" yarn lint and NODE_OPTIONS="--no-warnings" yarn dev show no warnings 👍 I wonder if it‘s possible to silence only --experimental-loader warnings in the stdout because other warning types can be potentially useful.

[forgo]

This issue occurs in typescript@4.5.2 that causes cannot find module "" in every import statement.

I downgraded typescript to 4.4.4 to workaround this issue.

Our team was having a very confounding issue that we could not pinpoint the origin of between a consuming app and shared library. Turns out somewhere we had upgraded typescript, but this error did not come up for a few small version upgrades of our library because we had not updated the yarn.lock.

Our issue was that removing the yarn.lock and installing fresh on our latest was causing every import statement like this to be effed.

If we incrementally and manually updated the package.json versions of our library and yarn && yarn build then the issue didn't show up. It was very confusing.

Thanks to this fellow @Paosder for finally helping me create a more stable library.

This seems definitely like a bug... or it's not clear that yarn has non-deterministic behavior simply for removing and recreating the yarn.lock between typescript versions?

Honestly, I'm having a hard time understanding what is going on, but downgrading to 4.4.4 definitely worked to allow me to remove the yarn.lock and re-build cleanly with our latest.

I would like a better understanding of what went wrong here so we can have a clean upgrade path moving forward.

Thanks!

[bestseob93]

The updated patch was released in 3.2.0-rc.5

yarn set version canary && yarn install

Thanks. TS issue solved by this. but, in next.js next dev doesn't stop compile..

[kachkaev]

@bestseob93 if you experience issues with Next.js canary, try downgrading to 12.0.4 and see vercel/next.js#31552. This is probably to do with Webpack, so not related to TS.

[bestseob93]

@kachkaev Thank you. but i'm using v10.2.3. (webpack v4) Even if I don't upgrade TypeScript version, I can't run it with canary alone.

nutshell..

next dev

with yarn v3.1.0, it works fine.
with yarn canary, it doesn't work.

[lamhungypl]

The updated patch was released in 3.2.0-rc.5

yarn set version canary && yarn install

This did not work for me (yarn 3.1.0, typescript: 4.5.2)
I downgraded to typescript 4.4.4 and it's work well

[merceyz]

yarn 3.1.0

That indicates you didn't run the provided commands

[merceyz]

Stable 3.1.1 has been released

yarn set version latest && yarn install

[lamhungypl]

For those ones cannot upgrade yarn version via yarn set version xxx, please check yarnPath in your .yarn.yml file.
for me, the upgrade command affected $HOME's yarn instead of the local project folder. This means you always have multiple versions of yarn in yarn/release, TIL.

[goongoguma]

For those yarn set version canary && yarn install does not work, ts2307 error could be occurred due to typescript configuration of your IDE. If you are using vscode try the command below.

yarn add -D @yarnpkg/pnpify
yarn dlx @yarnpkg/sdks vscode

and the reference is here

[DanielHoffmann]

For reference:

yarn versions >=3.2.0 updates fsevents in macos which causes Jest to hang and breaks terser-webpack-plugin v4 (the version that supports webpack v4) with the following error:

TypeError [ERR_INVALID_ARG_TYPE]: The "id" argument must be of type string. Received null
    at new NodeError (node:internal/errors:371:5)
    at validateString (node:internal/validators:119:11)
    at Module.require (node:internal/modules/cjs/loader:998:3)
    at require (node:internal/modules/cjs/helpers:94:18)
    at execMethod (/Users/danielhoffmann/ui/.yarn/cache/jest-worker-npm-26.6.2-46cbcd449f-f9afa3b88e.zip/node_modules/jest-worker/build/workers/processChild.js:113:16)
    at process.messageListener (/Users/danielhoffmann/ui/.yarn/cache/jest-worker-npm-26.6.2-46cbcd449f-f9afa3b88e.zip/node_modules/jest-worker/build/workers/processChild.js:46:7)
    at process.emit (node:events:394:28)
    at emit (node:internal/child_process:917:12)
    at processTicksAndRejections (node:internal/process/task_queues:84:21) {
  code: 'ERR_INVALID_ARG_TYPE'

the stack trace says the problem is with jest-worker dependency, but that dependency is also used by webpack-terser-plugin. Jest itself also uses it and from my testing updating to yarn >3.2.0 causes jest to hang before executing any tests which is fixable by using jest --runInBand

haven't tested webpack/terser-webpack-plugin v5

Downgrading to yarn 3.1.1 fixes the issue: yarn set version 3.1.1 and that version is also compatible with typescript 3.5

anyone can pinpoint exactly where I should report this problem? Seems the root problem is either in fsevents or maybe in jest-worker?

[merceyz]

@DanielHoffmann You're running into #4157 which is unrelated to this issue.