# Browserify: CommonJS require() in the browser, and when it still earns its place

> Browserify walks your require() graph and emits one bundle you can load with a script tag. It is a good fit for Node-flavoured code and npm modules that assume CommonJS, and a poor fit for projects that want native ES modules and tree shaking.

**browserify/browserify** — browser-side require() the node.js way

- Repository: https://github.com/browserify/browserify
- Website: http://browserify.org/
- Stars: 14,694 · Forks: 1,202
- Language: JavaScript
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/browserify-browserify

## The problem Browserify solves: require() that the browser never had

Browsers ship no module loader for CommonJS. If your code is written as `var foo = require('./foo.js')` and your dependencies come from npm, the browser has no idea what that means. Browserify exists to close that gap. It takes an entry file, recursively analyzes every require() call, and produces one bundle you serve with a single script tag. The audience is anyone with Node-style source and npm dependencies who wants a static file rather than a runtime loader. The README puts it plainly: browserify will recursively analyze all the require() calls in your app in order to build a bundle you can serve up to the browser in a single `<script>` tag. Module resolution follows Node's algorithm, so relative paths like './foo.js' and bare names like 'gamma' that search node_modules/ both work. That resolution behaviour is the whole value proposition, and it is also the constraint: the output is a bundle, not a module graph the browser resolves at runtime.

## How the bundle is built: module-deps, browser-pack and the stream pipeline

The mechanism is a pipeline. Browserify starts at the entry file and walks the require() graph with module-deps, which is listed in package.json as a dependency. Each resolved file is read, parsed, and its require() calls become edges to other files. The graph is then ordered by deps-sort and serialized by browser-pack into the single output file. By default module ids are converted into numerical indexes, which keeps the bundle small; the --full-paths flag turns that conversion off and preserves the original paths. Two options expose the internals. `--deps` prints the dependency array generated by module-deps instead of a bundle, and `--list` prints each file in the dependency graph, which the README suggests for makefiles. The global shim behaviour is a separate stage. With --detect-globals (default true) Browserify looks for process, global, __filename and __dirname and defines them only when present. --insert-globals skips detection and always inserts those definitions: the README states the benefit is faster builds and the cost is extra bytes. Node builtins are shimmed too, but only when you explicitly require() them or use their functionality. The README lists assert, buffer, console, constants, crypto, domain, events and http among the modules that resolve to a browser-specific shim.

## Installing Browserify and building your first bundle

Install it from npm, then point it at an entry file. The README gives the install command and the basic invocation.

```bash
npm install browserify
browserify main.js > bundle.js
```

The first command installs the package and its bin entry, which package.json maps to bin/cmd.js. The second writes the bundle to stdout, so the redirect creates bundle.js. Nothing is printed on success; the file simply appears. Load it with a script tag in your HTML, as the README instructs.

A minimal entry file looks like this, with relative and bare module paths mixed.

```js
var foo = require('./foo.js');
var bar = require('../lib/bar.js');
var gamma = require('gamma');

var elem = document.getElementById('result');
var x = foo(100) + bar('baz');
elem.textContent = gamma(x);
```

Exports work the CommonJS way, by assigning onto module.exports or exports.

```js
module.exports = function (n) { return n * 111 }
```

For debugging, add the --debug flag to emit source maps so you can debug your files separately. For a library you want to publish, --standalone generates a UMD bundle for the supplied export name; the README says it works with other module systems and sets the name as a window global when no module system is found. If a require() does not resolve and you want the build to continue anyway, --ignore-missing replaces it rather than failing. The repository also ships example directories, including example/api/, example/multiple_bundles/ and example/source_maps/, which are worth reading before you design your own build step.

## Where Browserify stops being the right tool

The output is a bundle, so there is no tree shaking. Every file reachable from the entry point is included unless you exclude it. That is a real cost for large dependency trees, and the README's own escape hatch is --noparse=FILE, which skips parsing a file entirely to make bundling much faster for giant libraries. Skipping the parse means skipping the require() analysis for that file, so it is a blunt instrument, not a substitute for dead-code elimination. The second limitation is Node compatibility. The README is honest that many npm modules that do not do IO will just work, and others take more work. Builtins are shimmed, but only when required, and the shim is a browser reimplementation with its own behaviour. The third is the build model. Browserify is a command that reads the graph and writes a file. It has no dev server and no hot reload in the core CLI. If your workflow depends on instant incremental feedback, the bundler itself will not give it to you; you would wrap it in a watcher, and the README does not document one. Finally, the package.json engines field says node >= 0.8, which tells you the project carries a long compatibility tail rather than tracking current Node releases tightly.

## Browserify compared with webpack, Vite and esbuild

The differences are architectural, not cosmetic. Browserify is a CommonJS-first bundler: it resolves and wraps require() calls and emits one script. Webpack also bundles, but it centres on loaders and plugins and its own module format, and it ships a dev server and hot module replacement in the same toolchain. Vite serves native ES modules to the browser during development and bundles for production, which is a different model entirely: development does not wait for a full bundle. esbuild is a Go bundler built around speed and a different transform pipeline. The practical split is this. If your source is CommonJS and your dependencies assume require(), Browserify maps onto that with almost no configuration. If your source is ESM and you care about tree shaking, Vite or esbuild are aimed at that problem and Browserify is not. One point of overlap worth knowing: the --standalone flag produces a UMD bundle, which is how Browserify output is consumed by other module systems, and that is a different publishing story from an ESM library build.

## Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-18. The most recent release is v17.0.1 from 2024-10-03; before that, v17.0.0 landed on 2020-10-10, and v16.5.1 on 2020-03-30. Read those dates together and the release cadence is slow: a major version every few years, with patch releases in between. That matters for upgrade planning. A dependency tree this wide, with entries such as browser-resolve, module-deps, browser-pack, stream-browserify and crypto-browserify, means a Node or npm change can surface through a transitive package rather than through Browserify itself. The licence is MIT, which is permissive and places few conditions on redistribution; the LICENSE file is at the repository root. This is not legal advice, and if you redistribute a bundle that embeds third-party npm code, the licences of those embedded packages apply to their own files, not just Browserify's. The changelog.markdown file is the place to read before bumping a major version.

## Conclusion

Adopt Browserify when your source is CommonJS, your dependencies are npm packages that assume require(), and you want one script tag rather than a dev server. Do not adopt it for a greenfield project that wants native ES modules, tree shaking, or a fast incremental rebuild loop, because Browserify has no tree shaking and rebuilds the graph from the entry file each run. Before committing, run browserify main.js --deps on your real entry point to see the dependency array, and check that every Node builtin you require has a browser shim in the compatibility list.

## FAQ

### How do I install Browserify?

Install it from npm with npm install browserify. The package.json bin field maps the browserify command to bin/cmd.js, so the CLI is available after install.

### What does Browserify do?

It recursively analyzes the require() calls in your app and builds a bundle you can serve to the browser in a single script tag. Module paths resolve using Node's module lookup algorithm, so relative paths and bare npm package names both work.

### How do I use Browserify?

Write an entry file that uses require(), then run browserify main.js > bundle.js and load bundle.js with a script tag in your HTML. Add --debug for source maps, and --standalone to generate a UMD bundle for a library export.

### Is Browserify dead?

The repository is not archived and the last push was on 2026-09-18, so work has happened recently. Releases are infrequent, though: v17.0.1 is from 2024-10-03 and v17.0.0 from 2020-10-10.

### What is crypto-browserify?

It is the browser shim for the Node crypto builtin. The README lists crypto among the modules that resolve to a browser-specific shim when you explicitly require() it or use its functionality.

### What is stream-browserify?

It is the browser shim for the Node stream builtin. The README lists stream among the modules that resolve to a browser-specific shim when you explicitly require() it or use its functionality.

## Sources

- [browserify/browserify on GitHub](https://github.com/browserify/browserify)
- [License: MIT](https://github.com/browserify/browserify/blob/master/LICENSE)
- [Project website](http://browserify.org/)
- [README](https://github.com/browserify/browserify/blob/master/README.md)
- [Releases](https://github.com/browserify/browserify/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/browserify-browserify