
40107 stars · MIT (named in the About sidebar) · v0.28.2 (2026-08-08), shown on /releases/latest as '08 Aug' with no year and settled from the npm registry's own publish timestamp, corroborated by a code date of 2026-08-09 · Track this in Scout
Joins many JavaScript, TypeScript and CSS files into one, in well under a second.
Radar check
What we found when we opened it. Every bar is one fact, with its date.
Last code pushed 9 Aug 2026, 2 months before this check.
Latest release v0.28.2 on 8 Aug 2026.
Public since June 2016, a little over 10 years.
40,107 stars and 1,364 forks.
34 commits and 28 new issues in the last 90 days.
130 contributors. 3 pull requests merged in 90 days.
No security policy file says how to report a problem. 3 published security advisories.
How the bars are scored
- Alive. Days since the last code push: a week or less 100, a month 90, three months 70, six months 50, a year 30, eighteen months 15, older 0.
- Releases. Age of the latest GitHub release, on a similar scale; no bar when the project publishes no releases.
- Maturity. Age of the project: eight years 100, five 90, three 70, two 55, one 40, six months 25, younger 10.
- Adoption. Stars on a log scale: 100,000 stars is 100, 10,000 is 80, 1,000 is 60, 100 is 40.
- Activity. Commits in the last 90 days: 300 or more 100, 100 85, 30 65, 10 45, any 25.
- Community. People who have contributed: 100 or more 100, 30 80, 10 60, 5 40, 2 25, one 10.
- Security. A published security policy 80, none 40; published advisories are listed, not scored.
Checked by Repo Radar on 25 Oct 2026 from the repository on GitHub. Covered in Edition 61.
▶Repo detailsthe review · specs · pros & cons · install
What it does
You point it at the file your application starts from. It reads JavaScript, TypeScript, JSX and CSS directly, follows every import, and writes out one bundled file, with unused code removed, the text shortened, and a map that lets a browser show the original source when something breaks. It also includes a small development server, a watch mode that rebuilds on save, and an interface for plugins. On its own published benchmark, joining a large library ten times over takes 0.39 seconds here against 14.91 seconds for the next tool, 34.10 seconds for another, and 41.21 seconds for the most common one — 106 times slower. The list of things it will not do is written down by its author: no type checking, no hot module replacement, no support for other frontend languages, and no interface for rewriting code trees. It is also not at version 1.0, and the author describes it as a late-stage beta where a minor version can break compatibility.
Why it matters
Who it suits. Anyone whose build step has become long enough to interrupt their thinking, which is most people on a project past a few hundred files. It also suits anyone who wants one small, predictable tool instead of a framework, because the published non-goals mean it will stay that size. Skip it if the project needs hot reloading or a framework's own file format, because those are explicitly out of scope and will stay out.
Verdict. Two minutes, and the best thing in this edition. The reason to read the author's own notes before adopting it is not that the project is in trou— version 0.28.2 was published on 8 August 2026 and code was pushed the next day — but that he has written down exactly where the tool stops, and said that active feature development is currently paused. That is a statement of scope, and it is worth more than a roadmap: it tells you what you are committing to. Three things to watch out for. Pin the exact version, because a minor release may break something; the official install command does this with --save-exact for that reason. Type checking is a separate step, so tsc still has to run. And the install delivers a compiled program through an optional per-platform package, which breaks if scripts are disabled, if a restrictive package registry is in the way, or if a folder of installed packages is copied between operating systems. If a richer plugin ecosystem matters more than speed, rollup/rollup is the long-established choice and the one most libraries are published with.
- Finishes in well under a second where the common alternative takes most of a minute.
- The author has published what it will never do, so its scope will not creep.
- One small program with no framework around it, usable from a command line, a script or Go.
- Still on a 0.x version line, where a minor release may break compatibility.
- No type checking and no hot reloading, so a second tool is always needed.
- The compiled program arrives through an optional package, which several ordinary install settings break.
- rollup/rollup
MIT, 26.3k stars; the same bundling job with a much larger plugin ecosystem and finer control over the output, which is why most libraries are published with it; it is 87 times slower on this project's own benchmark.
Track this in Scout - swc-project/swc
Apache-2.0, 34.2k stars; a very fast compiler for the same languages, written in Rust, used inside other tools rather than on its own, with bundling as a secondary concern.
Track this in Scout - parcel-bundler/parcel
MIT, 44.0k stars; aims to be the whole build tool with no configuration at all, which is exactly what this project has decided not to be; 38 times slower on the same benchmark.
Track this in Scout
npm install --save-exact --save-dev esbuild ./node_modules/.bin/esbuild --version