Bonsai: a tree view for the dependencies inside a webpack bundle

The question Bonsai answers is why a dependency is in the bundle at all

Bonsai is a tool for understanding the tree of dependencies inside a webpack bundle, and the README states the goal in one line: trim your javascript dependency tree. That is a narrower goal than bundle analysis in general. A size report tells you which packages are large; a dependency tree tells you who asked for them, which is the harder question. If a moment library ends up in your bundle, knowing that three different date utilities each pulled it in changes what you can do about it, and that is the kind of structural information a tree view shows and a flat list does not. The project is from Pinterest and lives under the Apache-2.0 licence, and the npm package is published under the name bonsai-analyzer rather than bonsai.

The documented quick start is a stats file dropped into a web page

The README's user guide is short. The quickest way to get started is to generate a webpack stats file and then drag and drop it into the analyzer hosted at https://pinterest.github.io/bonsai/analyze. That is the whole path: your build produces a JSON description of the bundle, and the browser application reads it. Nothing is uploaded to a server as far as the README describes, since the interaction is a drag and drop into a page, which means the stats file stays on the machine you dropped it on. More documentation and help live at https://pinterest.github.io/bonsai. The screenshot the README links, at bonsai-interface.png, is the visual reference for what you get: a tree rather than a flat list, with the expansion that makes the import graph legible. Note the practical implication, which the README does not spell out: you need a webpack configuration that emits a stats file, and generating one for a large production build is often a separate step from your normal build.

There is a CLI in the package as well as the browser app

The package manifest registers a binary named bonsai pointing at ./bin/cli.js, so the same analysis is available without opening a web page. The manifest identifies the package as bonsai-analyzer, version 0.4.0-alpha4, with the description Trim your dependency tree, and it lists webpack, tool, analyze, bundle and dependencies among its keywords.

{
  "name": "bonsai-analyzer",
  "description": "Trim your dependency tree.",
  "keywords": [
    "bonsai",
    "webpack",
    "tool",
    "analyze",
    "analyse",
    "bundle",
    "dependencies"
  ],
  "version": "0.4.0-alpha4",
  "private": false,
  "license": "Apache-2.0",
  "author": {
    "name": "Ryan Albrecht",
    "email": "[email protected]"
  },
  "contributors": [],
  "repository": "https://github.com/pinterest/bonsai",
  "bugs": "https://github.com/pinterest/bonsai/issues",
  "bin": {
    "bonsai": "./bin/cli.js"
  },

The repository layout explains why there are two front ends. There is a dev-server directory, a public directory, a src directory and a webpack.config.js, which is the shape of a browser application, and the bin entry points at a separate CLI script. So the two approaches differ in more than packaging. The browser route is a manual, visual exploration of one bundle at a time, and the CLI route is the same analysis driven from a script, which is what you want if you intend to compare builds over time or run it in CI. The README documents the drag and drop route only, so the CLI's flags and output are not described there.

A Create React App frontend with Flow types and Storybook

The stack is dated in an instructive way. The README states the project was bootstrapped with Create React App, and the manifest pins react and react-dom at 16.8.6 with react-redux at 7.0.2 and redux at 3.7.0, plus bootstrap 4.3.1 for styling and argparse for command line parsing. The repository carries a .flowconfig and a flow-typed directory along with flow-bin 0.104.0, so the source is type checked with Flow rather than TypeScript. There is a .storybook directory and several Storybook packages in devDependencies, including addon-actions and addon-storyshots, which points to a component library built with stories as tests. The .spelling file and markdown-spellcheck package show that the documentation prose is spell checked in CI, and .babelrc.cli alongside .babelrc suggests the CLI is compiled with a separate Babel configuration from the web app. The build badge in the README points at Travis CI, and .travis.yml is in the repository root.

What the README leaves out, and what that costs you

The documentation is genuinely thin and it is worth being specific about the gaps rather than complaining generally. The README does not document how to generate a webpack stats file, even though that is the first step of the quick start it gives. It does not document the CLI's options, its output format, or what it writes to disk, even though a binary called bonsai is registered in the manifest. It does not explain which webpack versions produce a stats file that Bonsai can read, nor how Bonsai handles the stats format changes between webpack versions. It also does not document how to act on a finding: there is no guidance on removing a dependency, on excluding one from a bundle, or on reading the tree to decide what to change. Those are all reasonable questions a reader will have after seeing the tree, and none of them are answered in the repository's README. The project also has no GitHub releases, so the version history has to be read from the npm version and the changelog rather than from a release page.

Apache-2.0 licensed, with development that has slowed

The licence is Apache-2.0, declared in the manifest, which permits commercial use and modification provided the notice and conditions are kept, and the LICENSE file at the repository root holds the text to read before shipping. The repository is not archived, but the last push was on 2026-04-02 and there are no GitHub releases, so there is no tagged history to track progress against. The npm version string is 0.4.0-alpha4, which is the clearest signal about how the project presents itself: a pre-release line on a zero major version. For an internal tool that is perfectly workable, but it means command line flags and output formats are not a stable contract. The dependency set also fixes the age of the tool: React 16.8.6, redux 3.7.0, bootstrap 4.3.1 and eslint 6.2.2 describe a project written against the JavaScript ecosystem of the late 2010s, and the Renovate and Greenkeeper configuration files show that dependency upkeep was automated rather than manual.

Editorial conclusion

Bonsai fits a frontend team that suspects a webpack bundle is carrying more than it needs and wants to see the tree of what imports what before deciding what to remove. It does not fit a team on a bundler other than webpack, since the input is a webpack stats file, and the npm package being at 0.4.0-alpha4 means you should expect interface churn. Verify first that your webpack build can emit a stats file, then read the tree with the web app before automating anything, and check the LICENSE file directly since the manifest declares Apache-2.0.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. pinterest/bonsai on GitHub
4. Project website
5. README