stampit: the size script prints a number and asserts nothing

The 5.0.1 release says CommonJS came back and the manifest has no require branch

The three most recent releases have titles that read like a story. v5.0.0 is titled ESM support, published 2025-10-05. Nine days later v5.0.1 is titled Return the CJS support. Then v5.1.0, on 2026-07-02, is titled TypeScript rewrite, and the top level of the tree now holds a single stampit.ts. The manifest in that tree disagrees with the middle title. The package declares type module, and its exports map has exactly two keys under the main entry, types pointing at the declaration file and default pointing at the compiled JavaScript. There is no require condition and no nested CommonJS branch, and the published files list contains the TypeScript source, the compiled JavaScript and the declaration file, with no separate CommonJS build among them. So either the CommonJS return was reverted, or it lives somewhere the manifest does not describe. Either way, reading the release title is not a reliable way to know whether require works.

The size script prints the gzip number and asserts nothing

The readme advertises a 1.3KB gzipped, or 4.8K minified, module, and the manifest contains the script that produces that figure. It runs the minifier over the compiled file with a long list of compression options including unsafe and pure_getters, reserves the identifiers stampit and Stamp, keeps those function names, writes a minified file, and then pipes it through a gzip size tool with the raw flag and the include-original flag. Here is the whole command:

Two things follow. The script minifies the compiled file into a temporary name, measures it, echoes the gzip result, and then deletes the minified file, and there is no comparison against a threshold anywhere in it, so a size regression produces a larger number in the log and a passing run. And the figure the readme quotes comes from a configuration that turns on unsafe and pure_getters compressions, which are the settings that let a minifier drop code it cannot prove safe.

npm t builds, typechecks, tests and then measures the bundle

The Development section documents two commands and the manifest defines nine scripts. The documented ones are npm t for unit tests and npm run test:benchmark for benchmarks. The one that matters is what npm t actually does:

So the unit test alias is a four stage pipeline. It compiles with the build configuration, runs a separate typecheck over the other configuration, executes the test files with the platform's own test runner, and finishes by measuring the bundle. There is no separate test script, which means there is no way to run the tests without also building and measuring them. The benchmark script is the opposite: it runs the test runner over the benchmark directory with no build step, so it uses whatever compiled output happens to be present. The continuous integration script chains the three of them in the order test, lint, benchmark.

The coverage script calls open, which is a macOS command

One script in the manifest will not run everywhere the library does. The coverage script is a single line that runs the coverage tool with an HTML reporter over the test command and then calls open on the generated report path. There is no cross-platform opener in the dependency list, so on Linux and Windows this script reaches the final command and fails, after having done the expensive part. That is a small thing on its own, and it is worth noticing mainly because it sits alongside two scripts that are carefully portable. The size script avoids any viewer by deleting its own output, and the test pipeline calls the platform test runner directly. The lint script is equally deliberate, using oxlint rather than the more common linter and skipping two patterns, the generated declaration file and the compiled JavaScript, so linting never reads the build output.

The API section is one line and two of the three examples are cut off

The page is 237 words and the API section is one sentence: see the website. There is no parameter list, no method table and no type reference on the page itself, so the documentation is entirely external. What the page does carry is three code examples and two of them are incomplete. The first builds a Character stamp with name and health, composes a Fighter that adds stamina and a fight method, and begins a Mage with mana before the listing stops mid-keyword on the methods key. The second is the What's the Point section, which motivates the library by asking how to inherit privileged methods with private data, then builds an Availability stamp that keeps its flag in a closure variable and exposes open, close and an isOpen method, before starting a Membership stamp with a members property and an add method and stopping mid-object. The third is not present at all.

The status list keeps four majors installable and one tag link loses its prefix

A Status section keeps every major line reachable, which is unusual and useful:

npm i stampit@1
npm i stampit@2
npm i stampit@3
npm i stampit@4
npm i stampit

Alongside each line there is a specification compatibility note, and those notes have not moved in two majors. Version 3 is compatible with the stamp specification up to and including 1.4. Versions 4 and 5 are both compatible with version 1.5 of the same specification, even though 5 changed the module format and was then rewritten in TypeScript. One detail is inconsistent: the breaking changes link for version 2 points at a release tag written without the v prefix, while versions 3, 4 and 5 point at tags written with it. So the first link in the list is also the only one that will not resolve by copying the pattern from its neighbours.

One source file, no runtime dependencies and a TypeScript 6 toolchain

The repository is nine entries and the library is one of them. There is a stampit.ts at the top level, a test directory, two TypeScript configurations named build and plain, an editor config, a licence file written as LICENSE.md rather than LICENSE, and the two package files. There is no dependencies key in the manifest at all, which is why a library whose headline is its weight in kilobytes can make that claim without arithmetic. The toolchain that produces it is more recent than the library. The dev dependencies include typescript on a version 6 range, oxlint for linting, c8 for coverage, uglify-js for the size measurement, a gzip size command line tool, prettier for formatting, a benchmark harness, and one entry whose purpose the readme never mentions, a package named check-compose. The two authors named are Eric Elliott and Vasyl Boroviak.

Editorial conclusion

Stampit is a reasonable choice if you want composition instead of class hierarchies and you are willing to hold the stamp specification in your head, because the API is small, the published surface is three files and there is nothing to install alongside it. It is a poor choice if you are still on CommonJS and reading release titles rather than manifests, since the fifth major line moved twice in a matter of months. Before you pin a version, check the exports map of the exact release you are installing rather than the release notes, and if the size claim matters to you, wire a threshold onto it yourself, because the project's own measurement step prints the figure and moves on.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. stampit-org/stampit on GitHub