resolve

resolve

implements the node require.resolve() algorithm such that you can require.resolve() on behalf of a file asynchronously and synchronously

[![github actions][actions-image]][actions-url] [![coverage][codecov-image]][codecov-url] [][license-url] [![Downloads][downloads-image]][downloads-url]

example

asynchronously resolve:

var resolve = require('resolve/async'); // or, require('resolve')
resolve('tap', { basedir: __dirname }, function (err, res) {
    if (err) console.error(err);
    else console.log(res);
});

$ node example/async.js
/home/substack/projects/node-resolve/node_modules/tap/lib/main.js

synchronously resolve:

var resolve = require('resolve/sync'); // or, `require('resolve').sync
var res = resolve('tap', { basedir: __dirname });
console.log(res);

$ node example/sync.js
/home/substack/projects/node-resolve/node_modules/tap/lib/main.js

methods

var resolve = require('resolve');
var async = require('resolve/async');
var sync = require('resolve/sync');

For both the synchronous and asynchronous methods, errors may have any of the following err.code values:

• MODULE_NOT_FOUND: the given path string (id) could not be resolved to a module
• INVALID_BASEDIR: the specified opts.basedir doesn't exist, or is not a directory
• INVALID_PACKAGE_MAIN: a package.json was encountered with an invalid main property (eg. not a string)
• ERR_PACKAGE_PATH_NOT_EXPORTED: the requested subpath is not defined in the package's exports field
• ERR_INVALID_PACKAGE_CONFIG: the package's exports field contains an invalid target
• INVALID_EXPORTS_CATEGORY: an invalid exportsCategory was specified

resolve(id, opts={}, cb)

Asynchronously resolve the module path string id into cb(err, res [, pkg]), where pkg (if defined) is the data from package.json.

options are:

• opts.basedir - directory to begin resolving from

• opts.package - package.json data applicable to the module being loaded

• opts.extensions - array of file extensions to search in order

• opts.includeCoreModules - set to false to exclude node core modules (e.g. fs) from the search

• opts.readFile - how to read files asynchronously

• opts.isFile - function to asynchronously test whether a file exists

• opts.isDirectory - function to asynchronously test whether a file exists and is a directory

• opts.realpath - function to asynchronously resolve a potential symlink to its real path

• opts.readPackage(readFile, pkgfile, cb) - function to asynchronously read and parse a package.json file

  • readFile - the passed opts.readFile or fs.readFile if not specified
  • pkgfile - path to package.json
  • cb - callback. a SyntaxError error argument will be ignored, all other error arguments will be treated as an error.

• opts.packageFilter(pkg, pkgfile, dir) - transform the parsed package.json contents before looking at the "main" field

  • pkg - package data
  • pkgfile - path to package.json
  • dir - directory that contains package.json

• opts.pathFilter(pkg, path, relativePath) - transform a path within a package

  • pkg - package data
  • path - the path being resolved
  • relativePath - the path relative from the package.json location
  • returns - a relative path that will be joined from the package.json location

• opts.paths - require.paths array to use if nothing is found on the normal node_modules recursive walk (probably don't use this)

  For advanced users, paths can also be a opts.paths(request, start, opts) function

  • request - the import specifier being resolved
  • start - lookup path
  • getNodeModulesDirs - a thunk (no-argument function) that returns the paths using standard node_modules resolution
  • opts - the resolution options

• opts.packageIterator(request, start, opts) - return the list of candidate paths where the packages sources may be found (probably don't use this)

  • request - the import specifier being resolved
  • start - lookup path
  • getPackageCandidates - a thunk (no-argument function) that returns the paths using standard node_modules resolution
  • opts - the resolution options

• opts.moduleDirectory - directory (or directories) in which to recursively look for modules. default: "node_modules"

• opts.preserveSymlinks - if true, doesn't resolve basedir to real path before resolving. This is the way Node resolves dependencies when executed with the --preserve-symlinks flag.

• opts.exportsCategory - a node-exports-info category string (e.g. 'conditions', 'patterns', 'pre-exports') that determines which exports field semantics to use. When set, resolution will use the package's exports field according to that category's supported conditions and features. This also enables self-reference support, allowing a package to import itself by name (e.g., require('my-package') from within my-package).

• opts.engines - determines exports field resolution based on Node.js version semantics:

  • When a string (e.g. '>= 14'): treated as a semver range, mapped to the most restrictive node-exports-info category covering that range.
  • When true: reads engines.node from the nearest package.json to basedir and uses the most restrictive category for that range.
  • When false or omitted: no engine-based exports resolution.
  • Throws if set to an empty string or non-boolean/non-string value.

Note: exportsCategory and engines are mutually exclusive - only one can be specified.

• opts.moduleSystem - either 'require' or 'import'. Determines which module system conditions are used when resolving the exports field. When 'require' (the default), the conditions include require; when 'import', the conditions include import instead. This option only has effect when exportsCategory or engines is also set. For example, given a package with exports: { ".": { "import": "./esm.js", "require": "./cjs.js" } }, resolving with moduleSystem: 'import' returns esm.js, while moduleSystem: 'require' (or omitting it) returns cjs.js.

• opts.conditions - an array of condition strings (e.g. ['require', 'node']) to use when resolving the exports field. If specified, this overrides the conditions that would otherwise be derived from the category (including those from moduleSystem). This option only has effect when exportsCategory or engines is also set.

default opts values:

…

resolve.sync(id, opts)

Synchronously resolve the module path string id, returning the result and throwing an error when id can't be resolved.

options are:

• opts.basedir - directory to begin resolving from

• opts.extensions - array of file extensions to search in order

• opts.includeCoreModules - set to false to exclude node core modules (e.g. fs) from the search

• opts.readFileSync - how to read files synchronously

• opts.isFile - function to synchronously test whether a file exists

• opts.isDirectory - function to synchronously test whether a file exists and is a directory

• opts.realpathSync - function to synchronously resolve a potential symlink to its real path

• opts.readPackageSync(readFileSync, pkgfile) - function to synchronously read and parse a package.json file. a thrown SyntaxError will be ignored, all other exceptions will propagate.

  • readFileSync - the passed opts.readFileSync or fs.readFileSync if not specified
  • pkgfile - path to package.json

• opts.packageFilter(pkg, pkgfile, dir) - transform the parsed package.json contents before looking at the "main" field

  • pkg - package data
  • pkgfile - path to package.json
  • dir - directory that contains package.json

• opts.pathFilter(pkg, path, relativePath) - transform a path within a package

  • pkg - package data
  • path - the path being resolved
  • relativePath - the path relative from the package.json location
  • returns - a relative path that will be joined from the package.json location

• opts.paths - require.paths array to use if nothing is found on the normal node_modules recursive walk (probably don't use this)

  For advanced users, paths can also be a opts.paths(request, start, opts) function

  • request - the import specifier being resolved
  • start - lookup path
  • getNodeModulesDirs - a thunk (no-argument function) that returns the paths using standard node_modules resolution
  • opts - the resolution options

• opts.packageIterator(request, start, opts) - return the list of candidate paths where the packages sources may be found (probably don't use this)

  • request - the import specifier being resolved
  • start - lookup path
  • getPackageCandidates - a thunk (no-argument function) that returns the paths using standard node_modules resolution
  • opts - the resolution options

• opts.moduleDirectory - directory (or directories) in which to recursively look for modules. default: "node_modules"

• opts.preserveSymlinks - if true, doesn't resolve basedir to real path before resolving. This is the way Node resolves dependencies when executed with the --preserve-symlinks flag.

• opts.exportsCategory - a node-exports-info category string (e.g. 'conditions', 'patterns', 'pre-exports') that determines which exports field semantics to use. When set, resolution will use the package's exports field according to that category's supported conditions and features. This also enables self-reference support, allowing a package to import itself by name (e.g., require('my-package') from within my-package).

• opts.enginesRange - a semver range string (e.g. '>= 14') that will be mapped to the most restrictive node-exports-info category covering that range.

• opts.engines - if true, reads engines.node from the nearest package.json to basedir and uses the most restrictive node-exports-info category for that range.

Note: exportsCategory, enginesRange, and engines are mutually exclusive - only one can be specified.

• opts.moduleSystem - either 'require' or 'import'. Determines which module system conditions are used when resolving the exports field. When 'require' (the default), the conditions include require; when 'import', the conditions include import instead. This option only has effect when exportsCategory or engines is also set. For example, given a package with exports: { ".": { "import": "./esm.js", "require": "./cjs.js" } }, resolving with moduleSystem: 'import' returns esm.js, while moduleSystem: 'require' (or omitting it) returns cjs.js.

• opts.conditions - an array of condition strings (e.g. ['require', 'node']) to use when resolving the exports field. If specified, this overrides the conditions that would otherwise be derived from the category (including those from moduleSystem). This option only has effect when one of exportsCategory, enginesRange, or engines is also set.

default opts values:

…

install

With npm do:

npm install resolve

license

MIT