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 🙏

© 2026 – Pkg Stats / Ryan Hefner

identify-package-manager

v1.2.0

Published

Check the used package manager in a given repository (npm, yarn classic, yarn berry, pnpm, bun)

Downloads

2,555

Readme

identify-package-manager 📦📦📦📦

Version

Detect the package manager used by a repository from any nested directory.

The package works as a CLI and as a library. It inspects packageManager metadata when present and falls back to common lockfiles such as package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lock, and bun.lockb.

Installation

npm install identify-package-manager

You can also run it without a global install:

npx identify-package-manager

CLI usage

Run the command anywhere inside the repository you want to inspect:

identify-package-manager [options] [directory]

Without any flag, the CLI prints the package manager name plus version info when it can determine one:

{
  "name": "yarn-berry",
  "version": {
    "simple": "4.6.1",
    "detailed": {
      "major": 4,
      "minor": 6,
      "patch": 1
    }
  }
}

Use --nameonly if you only need the normalized package manager name.

CLI options

| option | explanation | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | -h / --help | Display this package's help + usage info. | | -v / --version | Display this package's version number. | | -n / --nameonly | If set, the CLI only returns the package manager name (npm, yarn-classic, yarn-berry, pnpm, bun, or unknown). |

Library usage

import { identifyPackageManager } from "identify-package-manager";

const packageManagerInfo = identifyPackageManager();
console.log(packageManagerInfo);

const packageManagerName = identifyPackageManager(true);
console.log(packageManagerName);

You may also pass an explicit starting directory instead of relying on process.cwd():

const packageManagerInfo = identifyPackageManager(false, "/path/inside/repository");

Development

This repository uses npm, not Yarn or pnpm.

Useful commands:

npm test
npm run build
npm run verify

Commits are expected to use conventional commit messages. Local raw git commit is blocked by Husky on purpose; use the interactive helper instead:

npm run commit

That helper is intentionally a small local script instead of commitizen to avoid extra transitive maintenance and vulnerability surface.

Release workflow

Releases are automated with semantic-release in GitHub Actions.

  • CI runs npm ci and npm run verify.
  • Releases run on pushes to main or master, plus manual workflow dispatch.
  • The workflow is designed for protected branches and does not rely on pushing version or changelog commits back to git.
  • Git tags, npm releases, and GitHub Releases are the release source of truth.
  • Because of that, the package.json version committed on main can lag behind the latest published version.
  • The release workflow is set up for npm Trusted Publishing via GitHub Actions OIDC. No long-lived NPM_TOKEN should be required once the npm package is configured for trusted publishing.
  • When migrating an already-published package to semantic-release, add a vX.Y.Z tag to the latest already-published commit before the first automated release so semantic-release has the correct baseline.
  • npm run release:dry-run intentionally skips npm and GitHub publishing plugins and uses the local checkout as the release repository so you can preview release calculation without GitHub push credentials or npm auth.

You can preview the release process locally with:

npm run release:dry-run