Giter VIP home page Giter VIP logo

list-installed's Introduction

List Installed

A modern typed async alternative to read-installed and readdir-scoped-modules. Used to list and return all modules installed in node_modules, either just their names or their package.json files.

npm version npm downloads Module type: ESM Types in JS js-semistandard-style Follow @voxpelli@mastodon.social

Usage

Simple

npm install list-installed
import { listInstalled } from 'list-installed';

const pkgMap = await listInstalled(__dirname);

// Eg. iterate over the map
for (const [moduleName, pkg] of pkgMap.entries()) {
  // "moduleName" is identical to pkg.name
}

Methods

readdirScoped(path)

  • path: A string pointing to the path of a directory, either absolute or relative to the current working directory. Eg: ./node_modules/

Returns: AsyncGenerator that emits string of the name of each found directory

Similar functionality to readdir() from readdir-scoped-modules.

Returns all directories in path, with the scoped directories (like @foo) expanded and joined with the directories directly beneath them (like eg. @foo/abc and @foo/bar if abc and bar are the two directories in @foo, though it will never expand to @- or .-prefixed subdirectories and will hence never return @foo/@xyz or @foo/.bin).

Will not return any directory with a name that begins with ..

readdirModuleTree(path, depth=0)

  • path: A string pointing to the path of a directory, either absolute or relative to the current working directory. Eg: * ./node_modules/
  • depth: If set to 0, then this method is identical to readdirScoped(path), else this will return also modules found this many layers deep

Returns: AsyncGenerator that emits string paths, relative to the provided path, for each found module

Works the same as readdirScoped with the addition that if depth is set to higher than 0, then for every result of readdirScoped a node_modules subdirectory is looked for and if found, readdirScoped is run on that directory as well, prefixing all results with the parent name/prefix followed by /node_modules/.

For a two level deep tree the name returned would be like foo/node_modules/bar/node_modules/xyz, which one can do .split('/node_modules/') on to get in array shape.

listInstalled(path, [{ filter(pkg, alias) }])

  • path: A string pointing to the path of a module, either absolute or relative to the current working directory. Eg: ./*
  • filter: An optional callback that's similar to Array.prototype.filter(). Called with the resolved package file + if the module is aliased also the alias. Like Array.prototype.filter() it expects a truthy value back to include the item and a falsy to skip it. If the value returned is a Promise it will be resolved before the value is checked.

Returns: Promise that resolves to a Map that has string keys of the names of the found dependencies and values being the parsed package.json files.

Similar functionality to readInstalled() from read-installed.

Returns all top level dependencies found installed for a module.

Parses all package.json in parallell using read-pkg with results corresponding to the read-pkg NormalizedPackageJson type.

listInstalledGenerator(path, [{ filter }])

  • path: A string pointing to the path of a module, either absolute or relative to the current working directory. Eg: ./*
  • filter: An optional callback that's similar to Array.prototype.filter(). Called with the resolved package file + if the module is aliased also the alias. Like Array.prototype.filter() it expects a truthy value back to include the item and a falsy to skip it. If the value returned is a Promise it will be resolved before the value is checked.

Returns: AsyncGenerator that emits an object for each of the found dependencies. The object has two properties: alias, containing the alias when the module has been installed under an alias, and pkg, containing the parsed package.json files of the found dependencies.

Same as listInstalled(path), but rather than parsing package.json in parallell, it parses it sequentially at the pace that it is consumed.

workspaceLookup([options])

  • options.ignorePaths: An array of strings, string[], with paths to ignore during the lookup of workspaces
  • options.includeWorkspaceRoot=true: If set to false, then the workspace root will not be returned
  • options.path='.': A string pointing to the path of the module to look up the package.json and installed modules for
  • options.skipWorkspaces=false: If set, then no workspace lookup will be done and no workspaces be returned
  • options.workspace: An array of strings that should match the name of a workspace, its path or its path prefix. Only matching workspaces will be returned (as well as the root if includeWorkspaceRoot is true). If a workspace can't be found, then an error will be thrown when the generator has been fully iterated through.
  • ...and any other option available in read-workspaces

Returns: AsyncGenerator that emits { cwd, installed, pkg, workspace } for the root (if includeWorkspaceRoot is true) and each matching workspace (if skipWorkspaces isn't true). cwd is the path to the workspace or root, installed is an object that's the combined result of a listInstalled for the root and that cwd, pkg is the package.json of the workspace or root and workspace is the name of the workspace and is not set on the root result.

Used by

Similar modules

  • list-dependents โ€“ looks up the the modules depending on a provided module them and returns them in a similar way to this module
  • read-workspaces โ€“ provides the workspace lookup functionality that this module uses

list-installed's People

Contributors

renovate-bot avatar renovate[bot] avatar voxpelli avatar

Stargazers

 avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

Forkers

bmeck

list-installed's Issues

Increase performance of generator flow by buffering values

When one async generator uses another async generator as its source, the back pressure makes it so that the execution risks becoming sequential rather than parallel.

To improve the performance every such step should read ahead a bit on its source generator and that way prepare values for its own processing, so that ones its own processing of one value is done, the next value is already available to it.

Such a buffer with a size of 2-3 items could probably speed things up quite a bit (at least theoretically) and remove much of the need for special code in the non-generator flow:

list-installed/index.js

Lines 162 to 180 in a905a08

const pkgs = [];
try {
const dir = await opendir(nodeModulesDir);
for await (const relativeModulePath of readdirModuleTree(dir)) {
pkgs.push(readPkg({ cwd: pathModule.join(nodeModulesDir, relativeModulePath) }));
}
} catch (err) {
throw err.code === 'ENOENT' && err.path === nodeModulesDir
? new Error('Non-existing path set: ' + nodeModulesDir)
: err;
}
/** @type {Map<string, import('type-fest').PackageJson>} */
const pkgMap = new Map();
for (const pkg of await Promise.all(pkgs)) {
if (pkg.name) pkgMap.set(pkg.name, pkg);
}

Action Required: Fix Renovate Configuration

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: undefined. Note: this is a nested preset so please contact the preset author if you are unable to fix it yourself.

Add support for hoisted dependencies in workspaces? (npm/yarn/lerna)

Where the shared dependencies (or all non-conflicting dependencies) among the mono-repo project can be hoisted into to workspaces definition root.

Maybe add an option, like in #23, with a path to the workspaces definition and then list everything there after listing everything installed locally? Of course excluding all that has already been listed locally

Ability to determine if a dependency is a development dependency

Something I really liked about read-installed was that you could:

2.0.0
Breaking changes in 2.0.0:

The second argument is now an Object that contains the following keys:

depth optional, defaults to Infinity
log optional log Function
dev optional, default false, set to true to include devDependencies

The dev flag was super useful, in that you could exclude dev dependencies. This is useful in the tools we craft at Sonatype, because a lot of the times developers may want to weed out some of the noise the dev dependencies cause.

It would be nifty if this was available as an option for getting the list, but if there was a property on the returned objects with development: t/f that would be great too!

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Detected dependencies

github-actions
.github/workflows/codeql-analysis.yml
.github/workflows/dependency-review.yml
.github/workflows/lint.yml
.github/workflows/nodejs.yml
.github/workflows/ts-internal.yml
.github/workflows/ts.yml
npm
package.json
  • buffered-async-iterable ^0.3.0
  • pony-cause ^2.1.10
  • read-pkg ^9.0.1
  • read-workspaces ^1.2.0
  • @types/chai ^4.3.14
  • @types/chai-as-promised ^7.1.8
  • @types/chai-quantifiers ^1.0.4
  • @types/mocha ^10.0.6
  • @types/sinon ^17.0.3
  • @types/sinon-chai ^3.2.12
  • @voxpelli/eslint-config ^19.0.0
  • @voxpelli/tsconfig ^11.0.0
  • c8 ^9.1.0
  • chai ^4.4.1
  • chai-as-promised ^7.1.1
  • chai-quantifiers ^1.0.18
  • desm ^1.3.1
  • eslint ^8.57.0
  • eslint-plugin-es-x ^7.6.0
  • eslint-plugin-import ^2.29.1
  • eslint-plugin-jsdoc ^46.10.1
  • eslint-plugin-mocha ^10.4.1
  • eslint-plugin-n ^16.6.2
  • eslint-plugin-promise ^6.1.1
  • eslint-plugin-security ^1.7.1
  • eslint-plugin-sort-destructure-keys ^1.5.0
  • eslint-plugin-unicorn ^48.0.1
  • husky ^9.0.11
  • installed-check ^9.3.0
  • knip ^5.9.1
  • mocha ^10.4.0
  • npm-run-all2 ^6.1.2
  • sinon ^17.0.1
  • sinon-chai ^3.7.0
  • type-coverage ^2.28.1
  • typescript ~5.4.4
  • node >=18.6.0
test-published-types/package.json

  • Check this box to trigger a request for Renovate to run again on this repository

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.