mirror of
https://github.com/zebrajr/node.git
synced 2026-01-15 12:15:26 +00:00
8aac7da7d6
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>
Internal Modules
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.