stdlib splits a numerical library into separately installable npm packages

The install unit is a namespace, not the umbrella package

The architecture is described as fully decomposable, meaning APIs and functionality can be swapped out and mixed. In practice that shows up in the dependency list: `@stdlib/array` is pinned at ^0.5.1, `@stdlib/assert` at ^0.4.1, `@stdlib/blas` at ^0.4.1, `@stdlib/bench` at ^0.5.1, and `@stdlib/datasets` at ^0.4.0. Each is a separate npm package with its own version, so a project that wants a quantile function does not need the whole library, and a project that wants a random number generator picks a different package. The umbrella manifest lists those as dependencies, which means installing everything pulls a graph rather than one artifact.

Installing the whole project is called out as unnecessary for a web app

The installation guidance is organised by who you are rather than by platform, and it gives an explicit warning for one case. Someone doing data analysis and data science in JavaScript and Node.js, in the way they might use Python, Julia, R or MATLAB, is pointed at installing the entire project as a command-line utility. Someone building a web application with Browserify, Webpack or other bundlers is told to install individual packages, because installing the entire project is unnecessary and leads to slower installation times. Two narrower routes sit below that: creating custom bundles for a vendored payload, and loading a package through a `script` tag, either as an ES Module build or as a pre-built UMD browser bundle that can be pulled from a CDN such as unpkg or jsDelivr.

npm is the default and other managers are a command swap

Package management is handled by substitution rather than by separate instructions. The stated default is npm, and the note about other package managers such as yarn is that using them should be a matter of swapping npm commands for the relevant ones. That keeps one set of instructions valid across managers, at the cost of nobody maintaining tested command lines for the alternatives. The browser field in the manifest reinforces the dual target: it maps `process` to `process/`, so bundlers resolve the Node.js global to a shim when the same code is compiled for a browser. The package itself points `main` at ./lib.

package.json hands every task to make, then applies patches after install

The manifest is a thin shell over a Makefile. Almost every script is a one-word delegation: `lint` runs make lint, `repl` runs make repl, `test` runs make test, `benchmark` runs make benchmark, `examples` runs make examples, and there are separate targets for coverage, notes, cleaning, dependency checks and licence checks. One script is not a delegation at all. `postinstall` runs tools/scripts/apply_patches, so an install ends with a patch application step, which is worth knowing on a locked-down or reproducible build. The command line entry is a single binary, `stdlib`, pointing at ./bin/cli, and type declarations live under ./docs/types.

The Makefile builds from lib/node_modules with a second tools tree

Where the code lives is decided in the Makefile rather than in the manifest. `SRC_DIR` points at `$(ROOT_DIR)/lib/node_modules`, so sources sit inside a node_modules-shaped directory at the repository root, and `TOOLS_DIR` points at a separate `tools` directory whose packages land in `$(SRC_DIR)/@stdlib/_tools`. Build output, distributable files and temporary files each get their own overridable variable: `BUILD_DIR`, `DIST_DIR` and `TMP_DIR`. That separation is the practical shape of the project, with runtime code, build tooling and generated artefacts in three places. Two example entry points are checked in, examples/index.js and examples/index.mjs, so the CommonJS and module forms are both exercised from the repository itself.

Two licence terms in one field, not one

The repository carries an Apache-2.0 licence file and a NOTICE, and the copyright line in the README header reads 2018 The Stdlib Authors. The manifest field is different from that file: it reads `Apache-2.0 AND BSL-1.0`. That is a conjunction, which means two sets of terms apply to what ships rather than one, and it is the kind of detail that decides whether a package can go into a given repository. There is also a `check-licenses` make target among the scripts, so the terms are treated as something the tooling checks rather than as settled text. Privacy, governance, support, security, a roadmap and a citation file all sit at the repository root as well.

v0.4.0 and v0.4.1 landed a minute apart after a long quiet stretch

The release history is worth reading before you pin anything. v0.3.2 was published 2024-12-22, then v0.4.0 and v0.4.1 were both published on 2026-06-06, the second less than two minutes after the first, with the manifest now reading version 0.4.1. The last push to the default branch, develop, is dated 2026-11-01, so commits are landing well after the tags. Two consequences follow for a consumer. A caret range such as ^0.4.1 will not move you to a 0.5 line on its own, and a project expecting a steady stream of patch releases is looking at a history that does not deliver one, which makes reading the changelog before upgrading the sensible habit rather than a formality.

Native BLAS add-ons fall back to pure JavaScript when absent

The numerical reach is stated in counts: more than 150 special math functions, 35 or more probability distributions with support for probability density functions, cumulative distribution functions, quantiles and moments, 40 or more seedable pseudorandom number generators, 200 or more general utilities for data transformation, functional programming and asynchronous control flow, 200 or more assertion utilities, and 50 or more sample datasets. Speed comes from native add-ons that interface with BLAS libraries, and the fallback is a pure JavaScript implementation, so the same code path runs without a native build. On top of that sit a plot API for visualisation, a benchmark framework that supports TAP, a REPL with integrated help and examples, and TypeScript declarations for every function.

Editorial conclusion

stdlib suits a browser bundle that must stay small, a Node.js project that wants seeding and quantile functions with tests behind them, and anyone who wants a REPL to try mathematics in a terminal. It does not suit a project that wants one dependency and one version to pin, since the manifest here is a graph of @stdlib packages and two licence terms at once. Before committing, check which package actually holds the function you need rather than installing the umbrella package, read the licence field, which pairs Apache-2.0 with BSL-1.0, and confirm that a patch step runs on install.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes