[Bug] MODULE_NOT_FOUND with typescript and node builtins.

[JanMatas]

• I'd be willing to implement a fix

Describe the bug

Typescript never seems to consider builtin modules for node, which causes a bunch of warnings like:

(node:162808) [MODULE_NOT_FOUND] Error: @types/ioredis tried to access events. While this module is usually interpreted as a Node builtin, your resolver is running inside a non-Node resolution context where such builtins are ignored. Since events isn't otherwise declared in @types/ioredis's dependencies, this makes the require call ambiguous and unsound.

This seems to be the case in loose mode when there is another package which had declared dependency on the builtin module.

To Reproduce

I did my best to create a minimal repro: https://github.com/JanMatas/yarn2-builtin-warning-repro.
Just:

1. clone the repo
2. yarn
3. yarn tsc --watch
4. See a bunch of warnings

I tried to dig through the yarn code and through the "typescript patch". It seems like it is hardcoded that builtins are never considered when doing pnp resolution (considerBuiltins: false). The pnp resolution of builtins fails, but tsc still somehow manages to compile the code (I did not dig deep enough to find out how - it must have some sort of fallback).

Hence, the behaviour caused by this issues is limited to annoying warnings that appear if there is a fallback available on top level. The reproduction contains one of the modules (@types/ioredis) I found to emit warnings in our codebase (but there is many). I also added a random module that depends on events (aws-sdk). From code, it seems that selection of modules for repro is arbitrary, as long as one tries to access builtin and the other declares a dependency on the builtin.

I propose three solutions:

1. Simply extend the "warning silencer" ALWAYS_WARN_ON_FALLBACKS to work for top level fallbacks:

   berry/packages/yarnpkg-pnp/sources/loader/makeApi.ts

   Line 636 in c8cba54

   const reference = runtimeState.fallbackPool.get(dependencyName);

2. Consider builtins in typescript patch (it seems to be fairly involved tough)
3. Do not even consider builtins as fallbacks, so we always throw error and leave tsc to resolve it.

Happy to implement 1 and 3 and open a PR. Also happy to do 2, but I might need some guidance.

Environment if relevant (please complete the following information):

• OS: [e.g. OSX, Linux, Windows, ...] OSX
• Node version [e.g. 8.15.0, 10.15.1, ...] v14.15.0
• Yarn version [e.g. 2.0.0-rc1, ...] 2.3.3

BTW, thanks a lot for awesome project. We just migrated to yarn2 and really enjoy the speedup of app loads and yarn installs and especially smaller node_modules!

[merceyz]

Typescript never seems to consider builtin modules for node
The pnp resolution of builtins fails, but tsc still somehow manages to compile the code (I did not dig deep enough to find out how - it must have some sort of fallback).

That's because it's possible for users to install their own version of the builtins so it's only allowed to resolve those. Otherwise TypeScript gets the types from @types/node

[JanMatas]

Thanks, I did not know this is the case. I tried installing @types/node but this did not help. Maybe to rephrase the question here: how do I set the context here to resolve running resolver inside a non-Node resolution context? Or more generally, how do i resolve the warnings above?

[merceyz]

There is nothing to resolve, you just ignore them, it's how typescript finds types; they try a bunch of imports before falling back to @types/node.

[JanMatas]

Hi, thanks for the reply. Any advice how to ignore those? Our build logs and dev logs are flooded with those warnings. Would it make sense to add ENV variable or some flag to silence them, since they are not actionable?

[arcanis]

You can run Node with NODE_NO_WARNINGS=1 in your env, or call your scrips via node --no-warnings in the CLI, but you can't ignore specifically those messages.

[JanMatas]

Thank you! However, it does not seem viable for us to "blanket ignore" all warnings generated by node. Would you be open to accept a PR with an ENV flag similar to ALWAYS_WARN_ON_FALLBACKS that would disable the node types related warnings? Good name might be WARN_ON_BUILTIN_FALLBACKS which defaults to true?

[arcanis]

I'd tend to say no ... I see the loose mode as a way to ease migrations - not something that should be used forever. In this context, allowing to hide the warnings would I think have a detrimental effect, as many users would just blindly ignore them, regardless how right they are.

That being said, we sometimes bend the rules in special cases, and perhaps in this case we could automatically silence warnings for @types/ packages (on the basis that those packages are only ever used with TS , which will report errors by itself). I would be more favorable to this, because it wouldn't decrease the value of the warnings we emit (it would actually increase it, by decreasing the noise).

As a side note, if you really want this "ignore all" behavior, imo the right place for this would be in Node itself. Given that they provide the emitWarning utility, it would be nice to have support for something like NODE_NO_WARNINGS=MODULE_NOT_FOUND, that would only disable the specified set of warnings. It also seems a small enough change that they could accept it without being too controversial ... perhaps a good opportunity to contribute to Node itself? 😛

[luluyuzhi]

Has the problem been solved now?

(node:11972) [MODULE_NOT_FOUND] Error: typeorm tried to access events. While this module is usually interpreted as a Node builtin, your resolver is running inside a non-Node resolution context where such builtins are ignored. Since events isn't otherwise declared in typeorm's dependencies, this makes the require call ambiguous and unsound.
(node:11972) [MODULE_NOT_FOUND] Error: @types/node tried to access events. While this module is usually interpreted as a Node builtin, your resolver is running inside a non-Node resolution context where such builtins are ignored. Since events isn't otherwise declared in @types/node's dependencies, this makes the require call ambiguous and unsound.
(node:11972) [MODULE_NOT_FOUND] Error: @types/node tried to access util. While this module is usually interpreted as a Node builtin, your resolver is running inside a non-Node resolution context where such builtins are ignored. Since util isn't otherwise declared in @types/node's dependencies, this makes the require call ambiguous and unsound.
(node:11972) [MODULE_NOT_FOUND] Error: @nestjs/microservices tried to access events. While this module is usually interpreted as a Node builtin, your resolver is running inside a non-Node resolution context where such builtins are ignored. Since events isn't otherwise declared in @nestjs/microservices's dependencies, this makes the require call ambiguous and unsound.
(node:11972) [MODULE_NOT_FOUND] Error: grpc tried to access bytebuffer, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.
(node:11972) [MODULE_NOT_FOUND] Error: @types/bytebuffer tried to access long, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.
(node:11972) [MODULE_NOT_FOUND] Error: grpc tried to access events. While this module is usually interpreted as a Node builtin, your resolver is running inside a non-Node resolution context where such builtins are ignored. Since events isn't otherwise declared in grpc's dependencies, this makes the require call ambiguous and unsound.
(node:11972) [MODULE_NOT_FOUND] Error: @types/express tried to access serve-static, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.
(node:11972) [MODULE_NOT_FOUND] Error: @types/express-serve-static-core tried to access events. While this module is usually interpreted as a Node builtin, your resolver is running inside a non-Node resolution context where such builtins are ignored. Since events isn't otherwise declared in @types/express-serve-static-core's dependencies, this makes the require call ambiguous and unsound.
(node:11972) [MODULE_NOT_FOUND] Error: @types/express-serve-static-core tried to access range-parser, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.
(node:11972) [MODULE_NOT_FOUND] Error: @types/express-serve-static-core tried to access qs, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.
(node:11972) [MODULE_NOT_FOUND] Error: @types/serve-static tried to access mime, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.
(node:11972) [MODULE_NOT_FOUND] Error: @types/express tried to access body-parser, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.
(node:11972) [MODULE_NOT_FOUND] Error: @types/express tried to access qs, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.
(node:11972) [MODULE_NOT_FOUND] Error: @types/supertest tried to access superagent, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.
(node:11972) [MODULE_NOT_FOUND] Error: @types/superagent tried to access cookiejar, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.
(node:15988) [MODULE_NOT_FOUND] Error: follow-redirects tried to access debug (a peer dependency) but it isn't provided by its ancestors; this makes the require call ambiguous and unsound.
(node:15988) [MODULE_NOT_FOUND] Error: debug tried to access supports-color (a peer dependency) but it isn't provided by its ancestors; this makes the require call ambiguous and unsound.