Commit Graph

10 Commits

Author SHA1 Message Date
Antoine du Hamel
3d20582c0f
module: make CJS load from ESM loader
PR-URL: https://github.com/nodejs/node/pull/47999
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
Reviewed-By: Jacob Smith <jacob@frende.me>
2023-08-13 04:23:05 +00:00
Antoine du Hamel
693b6fbeac
module: fix unintended mutation
Refs: https://github.com/nodejs/node/pull/46061#issuecomment-1372246648
PR-URL: https://github.com/nodejs/node/pull/46108
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Jacob Smith <jacob@frende.me>
2023-01-07 15:36:51 +00:00
Denys Otrishko
c66e6471e7
lib: remove ERR_INVALID_OPT_VALUE and ERR_INVALID_OPT_VALUE_ENCODING
This will be a start to generalize all argument validation
errors. As currently we throw ARG/OPT, OUT_OF_RANGE, and other more
specific errors.
The OPT errors didn't bring much to the errors as it's just another
variant of ARG error which is sometimes more confusing (some of our code
used OPT errors to denote just argument validation errors presumably
because of similarity of OPT to 'option' and not 'options-object')
and they don't specify the name of the options object where the invalid
value is located. Much better approach would be to just specify path
to the invalid value in the name of the value as it is done in this PR
(i.e. 'options.format', 'options.publicKey.type' etc)

Also since this decreases a variety of errors we have it'd be easier to
reuse validation code across the codebase.

Refs: https://github.com/nodejs/node/pull/31251
Refs: https://github.com/nodejs/node/pull/34070#discussion_r467251009
Signed-off-by: Denys Otrishko <shishugi@gmail.com>

PR-URL: https://github.com/nodejs/node/pull/34682
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
2020-09-11 17:54:42 +03:00
Ruben Bridgewater
e038d6a1cd
test: refactor common.expectsError
This completely refactors the `expectsError` behavior: so far it's
almost identical to `assert.throws(fn, object)` in case it was used
with a function as first argument. It had a magical property check
that allowed to verify a functions `type` in case `type` was passed
used in the validation object. This pattern is now completely removed
and `assert.throws()` should be used instead.

The main intent for `common.expectsError()` is to verify error cases
for callback based APIs. This is now more flexible by accepting all
validation possibilites that `assert.throws()` accepts as well. No
magical properties exist anymore. This reduces surprising behavior
for developers who are not used to the Node.js core code base.

This has the side effect that `common` is used significantly less
frequent.

PR-URL: https://github.com/nodejs/node/pull/31092
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
2019-12-31 15:54:20 +01:00
cjihrig
58fc168807
module: handle empty require.resolve() options
If require.resolve() is passed an options object, but
the paths option is not present, then use the default
require.resolve() paths.

PR-URL: https://github.com/nodejs/node/pull/28078
Fixes: https://github.com/nodejs/node/issues/28077
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
2019-06-11 10:20:31 -07:00
cjihrig
a608caa5ff module: improve resolve paths validation
This commit adds input validation to require.resolve()'s
paths option. Prior to this change, passing in a non-array
value lead to a misleading 'module not found' error.

Refs: https://github.com/nodejs/node/issues/27583

PR-URL: https://github.com/nodejs/node/pull/27613
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
2019-05-10 11:26:26 -07:00
cjihrig
dac1143fc8
module: handle relative paths in resolve paths
This commit adds support for relative paths in
require.resolve()'s paths option.

PR-URL: https://github.com/nodejs/node/pull/27598
Fixes: https://github.com/nodejs/node/issues/27583
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
2019-05-09 14:16:05 -04:00
Ali Ijaz Sheikh
a02e3e2d5f lib: improve error message for MODULE_NOT_FOUND
Include the require stack in the reported error message.

PR-URL: https://github.com/nodejs/node/pull/25690
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
2019-02-15 12:52:05 -08:00
cjihrig
60ce2fd827
module: don't search in require.resolve.paths
The paths used by require.resolve() should be treated as
starting points for module resolution, and not actually
searched.

PR-URL: https://github.com/nodejs/node/pull/23683
Fixes: https://github.com/nodejs/node/issues/18408
Refs: https://github.com/nodejs/node/issues/23643
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
2018-12-11 00:53:02 -05:00
cjihrig
9c6f6b0633
module: support custom paths to require.resolve()
This commit allows custom lookup paths to be passed to
require.resolve(). It also adds require.resolve.paths()
which retrieves the default resolution paths.

Fixes: https://github.com/nodejs/node/issues/5963
Fixes: https://github.com/nodejs/node/issues/16389
PR-URL: https://github.com/nodejs/node/pull/16397
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Wyatt Preul <wpreul@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
2017-10-25 09:14:14 -04:00