mirror of
https://github.com/nodejs/node.git
synced 2026-11-09 15:11:11 -05:00
Paul Bouchon
1b2de5e052
A `.js` file with no `"type"` in the nearest package.json has no format of its own, and `defaultGetFormat()` reports it as null. `--check` passed that null straight to `wrapSafe()`, which parses as CommonJS. Module syntax makes that parse bail out early, so the file was reported as valid and `--check` exited 0 even though it is not valid JavaScript under either goal. At load time the goal for such a file is decided by looking for module syntax in the source. Decide it the same way here, so the file is parsed as a module and its real syntax error is reported. Files whose format is known are unaffected, as are ambiguous files without module syntax, which are still parsed as CommonJS. Fixes: https://github.com/nodejs/node/issues/65202 Signed-off-by: Paul Bouchon <mail@bitpshr.net> PR-URL: https://github.com/nodejs/node/pull/65203 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Aviv Keller <me@aviv.sh>
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.