npmpackage.info

Gathering detailed insights and metrics for snyk-resolve-deps

Other packages similar to snyk-resolve-deps

dotnet-deps-parser

5.6.0

Generate a dep tree given a collection of manifests

snyk-resolve

1.1.0

Resolves the location of a node package given a path

glslify-deps

1.3.2

Walk the dependency graph of a glslify shader.

snyk-gradle-plugin

4.7.0

Snyk CLI Gradle plugin

Gathering detailed insights and metrics for snyk-resolve-deps

snyk-resolve-deps

Resolves a node package tree with combined support for both npm@2 and npm@3

4.9.0

NOASSERTION

TypeScript

54,487,676 3.4

Installations

npm install snyk-resolve-deps

Pull Requests

Open

2

Total

83

Closed

16

Merged

65

Issues

Open

0

Total

0

Closed

0

Releases

v4.9.0

Published on 05 Jun 2024

v4.8.0

Published on 07 Feb 2024

v4.7.3

Published on 18 Aug 2021

v4.7.2

Published on 03 Feb 2021

v4.7.1

Published on 08 Jul 2020

v4.7.0

Published on 15 Jun 2020

View all 47 releases

Developer

Snyk

Developer Guide

BETA

Module System

CommonJS

Min. Node Version

Typescript Support

Yes

Node Version

16.20.2

NPM Version

8.19.4 Statistics

28 Stars

181 Commits

12 Forks

108 Watching

20 Branches

43 Contributors

Updated on 29 Oct 2024

Languages

TypeScript (52.68%)

JavaScript (47.06%)

Makefile (0.27%)

Total Downloads

Cumulative downloads

Total Downloads

54,487,676

Last day

18.7%

10,300

Compared to previous day

Last week

9.2%

60,235

Compared to previous week

Last month

61.6%

195,086

Compared to previous month

Last year

-41.9%

2,199,823

Compared to previous year

Daily Downloads

Weekly Downloads

Monthly Downloads

Yearly Downloads

Dependencies

ansicolors debug lodash lru-cache semver snyk-module snyk-resolve snyk-tree snyk-try-require then-fs

Dev Dependencies

@types/node @types/semver jest ts-jest ts-node tslint typescript

Versions

snyk-resolve-deps

This package will create a virtual tree representation of a node package's dependencies, supporting both npm@2 and npm@3 directory structures.

Note that the output differs from the npm ls output in that deduped packages are resolved to their owners.

Programatical usage

1let resolveDeps = require('snyk-resolve-deps');
2let asTree = require('snyk-tree');
3let options = { dev: true };
4
5resolveDeps(process.cwd(), options).then(function (tree) {
6  console.log(asTree(tree));
7}).catch(function (error) {
8  // error is usually limited to unknown directory
9  console.log(error.stack);
10  process.exit(1);
11});

API

resolveDeps(root, options)

root: path to project root
options (optional)
- dev: [default, false] report only development options
- extraFields: [default, undefined] extract extra fields from dependencies' package.json files. example: ['files']
- noFromArrays: [default, false] don't include from arrays with list of deps from root on every node
- file: [default, 'package.json'] location of the package file

How it works

To fully support npm@2 and npm@3 two passes of the tree are required:

1. The physical pass on the directory structure

The module will start by reading the package.json from the target directory, capture the metadata and then read through each recursive node_modules directory.

This creates the physicalTree object. In npm@3 this will usually yield an object with the root metadata (name, version, etc) and then a dependencies object that contains every dependency across the entire code base. This is not the true representation of the package relationships so we need to make the second pass.

There are also edge cases that need to be handled, particularly when a dev or prod dependency hasn't been loaded into the physical tree because it has been missed. This can be either because the package is missing from the project, or (more likely) because the dependencies is much higher up and outside of the original directory that was scanned. So a second check is run to find those missing modules, using the snyk-resolve module.

Note: code found in lib/deps.js

2. The virtual pass using package metadata

The next pass uses the physicalTree as the starting point, but uses the dependencies and devDependencies properties from the package.json metadata. It will iterate through the dependencies and resolve the correct dependency package from the physical tree based on similar methods that the require module loading system will use (this is in lib/pluck.js).

Finally, once the virtual tree is constructed, a pass is made to check for unused packages from the original physicalTree, which are marked as extraneous: true, and if the optional dev flag is false, all devDependencies are stripped.

Note: code found in lib/logical.js

Misc

No vulnerabilities found.

10

Dangerous-Workflow

Determines if the project's GitHub Action workflows avoid dangerous patterns.

10

Binary-Artifacts

Determines if the project has generated executable (binary) artifacts in the source repository.

9

License

Determines if the project has defined a license.

7

Code-Review

Determines if the project requires human code review before pull requests (aka merge requests) are merged.

0

Maintained

Determines if the project is "actively maintained".

0

Token-Permissions

Determines if the project's workflows follow the principle of least privilege.

0

CII-Best-Practices

Determines if the project has an OpenSSF (formerly CII) Best Practices Badge.

0

Pinned-Dependencies

Determines if the project has declared and pinned the dependencies of its build process.

0

Security-Policy

Determines if the project has published a security policy.

0

Fuzzing

Determines if the project uses fuzzing.

0

SAST

Determines if the project uses static code analysis.

0

Vulnerabilities

Determines if the project has open, known unfixed vulnerabilities.

Score

3.4

/10

Last Scanned on 2024-11-25

The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.

Learn More