This tracks the asynchronicity in the ModuleWraps when they turn out to
contain TLA after instantiation, and throw the right error
(ERR_REQUIRE_ASYNC_MODULE) when it's required again. It removes
the freezing of ModuleWraps since it's not meaningful to freeze
this when the rest of the module loader is mutable, and we
can record the asynchronicity in the ModuleWrap right after
compilation after we get a V8 upgrade that contains
v8::Module::HasTopLevelAwait() instead of searching through
the module graph repeatedly which can be slow.
PR-URL: https://github.com/nodejs/node/pull/55520
Fixes: https://github.com/nodejs/node/issues/55516
Refs: https://github.com/nodejs/node/issues/52697
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Jacob Smith <jacob@frende.me>
The modules located in lib/internal directory are exclusively meant
for internal usage within the Node.js core. They are not intended to
be accessed via user modules require(). These modules may change at
any point in time. Relying on these internal modules outside the core
is not supported and can lead to unpredictable behavior.
In certain scenarios, accessing these internal modules for debugging or
experimental purposes might be necessary. Node.js provides the --expose-internals
flag to expose these modules to userland code. This flag only exists to
assist Node.js maintainers with debugging internals. It is not meant for
use outside the project.
8aac7da7d6