npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@gzaripov/depend

v2.2.0

Published

dependency analyzer and fixer

Downloads

3

Readme

depend

A tool for analysing, visualizing and syncing version numbers in a monorepo.

This tool parses all package.json files described in your lerna.json or that match a given glob-expression. All packages found are assumed to be part of one monorepo.

Linting

Based on the parsed packages, linting rules are computed. Based on those rules, hints are computed and can be displayed using --hint and applied with --fix. Strategies add additional rules for ensuring packages install the same external dependencies. By default, only rules are computed that ensure that every package installs the latest version of each package found in the monorepo.

Analysis

--list prints all package versions found in the monorepo. Based on the used rules, packages will be rendered in different colours:

  • Green => nothing to do.
  • Yellow => rules available to resolve the conflict.
  • Red => no rule available to resolve this conflict.

If no rules are available, set a strategy or fix the issue by using --pick.

Usage

depend --lerna "{path/to/lerna/project}" [...options]
depend --expr "{glob}" [...options]

Options

--lerna, -l "{path}"

Evaluate all package.json files defined in the packages field found <path>/lerna.json file.

--expr, -e "{glob}"

Defines the glob expression that will be used to search the filesystem for package.json files.

--fix

Fixes the packages according to the computed versions.

--graph, -g ["{filter}"]

Prints a graphviz compatible output that can be converted to an image.

--list

prints all package versions found in the monorepo.

'--showRules'

prints all computed rules.

Examples

Consider following repo:

packages/foo/package.json:

{
  "name": "foo",
  "version": "0.0.1",
  "dependencies": {
    "react-native": "0.54.2",
    "bar": "0.0.1"
  }
}

packages/bar/package.json:

{
  "name": "bar",
  "version": "0.0.2",
  "dependencies": {
    "react-native": "0.53.1",
    "glob": "6.2.1"
  }
}

depend -l . -g outputs all dependencies in .dot format:

  digraph {
    "[email protected]" -> "[email protected]";
    "[email protected]" -> "[email protected]";
    "[email protected]" -> "[email protected]";
    "[email protected]" -> "[email protected]";
  }

depend -l . -g "*=>react-native" will only outputs the subset that has react-native as a dependency:

digraph {
  "[email protected]" -> "[email protected]";
  "[email protected]" -> "[email protected]";
}

depend -l . -g "foo=>*" will only outputs the subset that has react-native as a dependency:

digraph {
  "[email protected]" -> "[email protected]";
  "[email protected]" -> "[email protected]";
}

Rendering Svgs

Depend itself does not have any rendering capabilities but --graph output can be directly piped into a graphviz renderer. fdp and circo can be obtained by installing the graphviz package.

depend -l . -g "@times-components/*=>dextrose@" | fdp -Tsvg -o dextrose.svg

dextrose

depend -l . -g "*/ad@ => *" | circo -Tgif -o ad.gif

ad

--pick, -p {package}@{version}

Adds {package}@{version} to the set of rules. Use this in conjunction with --hint to verify the expected behaviour and use --fix to apply the changes.

depend -l . --pick [email protected] --hint would set all react-native dependencies to 0.54.2

Filter

The filter allows you to restrict the nodes that will be part of the graph.

The graph is described as a set of relationship of the shape package@version => dependency@version. A Node is included in the graph if the supplied pattern matches the relationship. Currently only supported placeholder symbol is "*".

Examples

=>[email protected].*

everything that installs react-native ver0.50.*

=>jest

everything that installs jest

@times-components/*=>*, @times-components

all the dependencies of all times-components packages

*=>* , ``, *

everything

--bail

exit with code 1 if packages don't install the expected versions.

strategies [--strategy, -s]

Strategies compute additional rules how to resolve version conflicts of external (dev)dependencies within the monorepo.

Dependencies that are also packages of the monorepo, are always (suggested to be) set to the latest version found in the monorepo irrespective of the chosen strategy.

conservative

pick the oldest used version

progressive

pick the newest used version

majority

use the version that is used by the majority of packages in your repo

majorityConservative

as majority but on a tie pick the older version

majorityProgressive

as majority but on a tie pick the newer version

Limitations

Strategies progressive and conservative don't support version ranges.