The term "native module" dates back to some of the oldest code
in the code base. Within the context of Node.js core it usually
refers to modules that are native to Node.js (e.g. fs, http),
but it can cause confusion for people who don't work on this
part of the code base, as "native module" can also refer to
native addons - which is even the case in some of the API
docs and error messages.
This patch tries to make the usage of these terms more consistent.
Now within the context of Node.js core:
- JavaScript scripts that are built-in to Node.js are now referred
to as "built-in(s)". If they are available as modules,
they can also be referred to as "built-in module(s)".
- Dynamically-linked shared objects that are loaded into
the Node.js processes are referred to as "addons".
We will try to avoid using the term "native modules" because it could
be ambiguous.
Changes in this patch:
File names:
- node_native_module.h -> node_builtins.h,
- node_native_module.cc -> node_builtins.cc
C++ binding names:
- `native_module` -> `builtins`
`node::Environment`:
- `native_modules_without_cache` -> `builtins_without_cache`
- `native_modules_with_cache` -> `builtins_with_cache`
- `native_modules_in_snapshot` -> `builtins_in_cache`
- `native_module_require` -> `builtin_module_require`
`node::EnvSerializeInfo`:
- `native_modules` -> `builtins
`node::native_module::NativeModuleLoader`:
- `native_module` namespace -> `builtins` namespace
- `NativeModuleLoader` -> `BuiltinLoader`
- `NativeModuleRecordMap` -> `BuiltinSourceMap`
- `NativeModuleCacheMap` -> `BuiltinCodeCacheMap`
- `ModuleIds` -> `BuiltinIds`
- `ModuleCategories` -> `BuiltinCategories`
- `LoadBuiltinModuleSource` -> `LoadBuiltinSource`
`loader.js`:
- `NativeModule` -> `BuiltinModule` (the `NativeModule` name used in
`process.moduleLoadList` is kept for compatibility)
And other clarifications in the documentation and comments.
PR-URL: https://github.com/nodejs/node/pull/44135
Fixes: https://github.com/nodejs/node/issues/44036
Reviewed-By: Jacob Smith <jacob@frende.me>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Jan Krems <jan.krems@gmail.com>
doc: update ESM hook examples
esm: fix unsafe primordial
doc: fix ESM example linting
esm: allow source of type ArrayBuffer
doc: update ESM hook changelog to include resolve format
esm: allow all ArrayBuffers and TypedArrays for load hook source
doc: tidy code & API docs
doc: convert ESM source table header from Title Case to Sentence case
doc: add detailed explanation for getPackageType
esm: add caveat that ESMLoader::import() must NOT be renamed
esm: tidy code declaration of getFormat protocolHandlers
doc: correct ESM doc link (bad conflict resolution)
doc: update ESM hook limitation for CJS
esm: tweak preload description
doc: update ESM getPackageType() example explanation
PR-URL: https://github.com/nodejs/node/pull/37468
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Guy Bedford <guybedford@gmail.com>
Reviewed-By: Bradley Farias <bradley.meck@gmail.com>
Reviewed-By: Geoffrey Booth <webmaster@geoffreybooth.com>
For every object that inherits from `Object.prototype`, the REPL
includes the `Object.prototype` methods in its autocompletion.
This is already a little noisy, but in particular, this also
includes the legacy `__defineGetter__` family of methods;
since those are deprecated and not in practical use anymore,
it helps reduce noise a bit to remove them.
This commit does not remove `__proto__` as it is a little
more popular and, despite its downsides, a slightly more convenient
way to access the prototype of an object in the REPL than
`Object.getPrototypeOf(...)`.
PR-URL: https://github.com/nodejs/node/pull/39576
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
It’s not okay for the REPL to be blocked for multiple seconds after
entering `require('` because the completion is performing blocking
fs operations on potentially huge directories. Turning the REPL
completion function asynchronous would be the right thing to do here,
but unfortunately the way the code is structured doesn’t play well
with that (in particular, it breaks the preview feature).
Therefore, disable these blocking calls by default.
Refs: https://github.com/nodejs/node/pull/33282#issuecomment-733646794
PR-URL: https://github.com/nodejs/node/pull/36564
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Throughout our messages and docs, we refer to the Control key in a
surprisingly varied number of ways:
* Control
* Ctrl
* Cntl
* varied capitalization on the above (e.g., ctrl vs. Ctrl)
Then, in key combinations:
* One of the items from the previous list followed by `-`
* ... or followed by `+`
* ... surrounded or not by `<` and `>`
* ... and inside backticks or not
* ... or just `^`
This is the start of standardization on the formulation recommended by
the Microsoft Style Guide (e.g., **Ctrl+C**).
PR-URL: https://github.com/nodejs/node/pull/35270
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
User-facing error messages should use _REPL_ for the general REPL and
not _repl_ which should be reserved for referring to the module itself,
etc. _REPL_ is an acronym, so it should be capitalized, as it generally
is in documentation in other technologies, and is usually in our own
documentation. This fixes a few inconsistent usages in lib/repl.js.
PR-URL: https://github.com/nodejs/node/pull/34643
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Ricky Zhou <0x19951125@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
This makes sure all REPL instances check for the NODE_REPL_MODE
environment variable in case the `replMode` is not passed through
as option.
At the same time this simplifies the internal REPL code significantly.
Signed-off-by: Ruben Bridgewater <ruben@bridgewater.de>
PR-URL: https://github.com/nodejs/node/pull/33461
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Daeyeon Jeong