browserify/resolve — 796★ on GitHub (JavaScript). Implements the node.js require.resolve() algorithm
Snapshot summary built from the project's own GitHub metadata — there's no written TopGit review yet. The page will update automatically when a full review is published.
WHY NO REVIEW YET
TopGit writes full reviews for the most-starred, most-requested repositories. This page is a snapshot until then — see the READ ME tab for the original README in full.
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:
{
paths: [],
basedir: __dirname,
extensions: ['.js'],
includeCoreModules: true,
readFile: fs.readFile,
isFile: function isFile(file, cb) {
fs.stat(file, function (err, stat) {
if (!err) {
return cb(null, stat.isFile() || stat.isFIFO());
}
if (err.code === 'ENOENT' || err.code === 'ENOTDIR') return cb(null, false);
return cb(err);
});
},
isDirectory: function isDirectory(dir, cb) {
fs.stat(dir, function (err, stat) {
if (!err) {
return cb(null, stat.isDirectory());
}
if (err.code === 'ENOENT' || err.code === 'ENOTDIR') return cb(null, false);
return cb(err);
});
},
realpath: function realpath(file, cb) {
var realpath = typeof fs.realpath.native === 'function' ? fs.realpath.native : fs.realpath;
realpath(file, function (realPathErr, realPath) {
if (realPathErr && realPathErr.code !== 'ENOENT') cb(realPathErr);
else cb(null, realPathErr ? file : realPath);
});
},
readPackage: function defaultReadPackage(readFile, pkgfile, cb) {
readFile(pkgfile, function (readFileErr, body) {
if (readFileErr) cb(readFileErr);
else {
try {
var pkg = JSON.parse(body);
cb(null, pkg);
} catch (jsonErr) {
cb(jsonErr);
}
}
});
},
moduleDirectory: 'node_modules',
preserveSymlinks: false
}
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:
{
paths: [],
basedir: __dirname,
extensions: ['.js'],
includeCoreModules: true,
readFileSync: fs.readFileSync,
isFile: function isFile(file) {
try {
var stat = fs.statSync(file);
} catch (e) {
if (e && (e.code === 'ENOENT' || e.code === 'ENOTDIR')) return false;
throw e;
}
return stat.isFile() || stat.isFIFO();
},
isDirectory: function isDirectory(dir) {
try {
var stat = fs.statSync(dir);
} catch (e) {
if (e && (e.code === 'ENOENT' || e.code === 'ENOTDIR')) return false;
throw e;
}
return stat.isDirectory();
},
realpathSync: function realpathSync(file) {
try {
var realpath = typeof fs.realpathSync.native === 'function' ? fs.realpathSync.native : fs.realpathSync;
return realpath(file);
} catch (realPathErr) {
if (realPathErr.code !== 'ENOENT') {
throw realPathErr;
}
}
return file;
},
readPackageSync: function defaultReadPackageSync(readFileSync, pkgfile) {
return JSON.parse(readFileSync(pkgfile));
},
moduleDirectory: 'node_modules',
preserveSymlinks: false
}
The most recent commit recorded on browserify/resolve was 1 month ago, based on the GitHub push timestamp. The repository has 189 forks — one of the better signals of community interest.
How many stars does browserify/resolve have?
browserify/resolve has 796 GitHub stars — refresh the page for the live number, or check github.com/browserify/resolve. TopGit mirrors GitHub's count but does not claim minute-by-minute accuracy.
Is browserify/resolve open source?
Yes — browserify/resolve ships under the MIT license, which makes its source code freely readable (and, depending on license terms, forkable and reusable). Source: github.com/browserify/resolve.
What else is in the Backend space?
browserify/resolve is tracked by TopGit under the Backend category, alongside 8 GitHub-tagged topics. Trending and Topics pages list peer repositories of comparable stars and language.
What is browserify/resolve?
browserify/resolve (browserify/resolve) is a JavaScript project on GitHub. From the project's own README: Implements the node.js require.resolve() algorithm
What language is browserify/resolve written in?
browserify/resolve is written primarily in JavaScript. GitHub's language field is based on the largest share of bytes in the default branch.
What license does browserify/resolve use?
browserify/resolve is released under the MIT license. Always verify the LICENSE file directly on GitHub for the authoritative terms — license strings can be edited out of sync with a project's actual stance.
Where do I read more about browserify/resolve?
This TopGit page is a snapshot — the READ ME tab shows the project's own README content (links stripped, images preserved). The GitHub repository at github.com/browserify/resolve is the definitive source.
Read full README in the tab above.
Curious whether resolve is right for you?
Let ChatGPT, Claude, or Perplexity look into it — click below and see what AI actually says about resolve.