mrkeyoor.com_
Fri 16 Oct 18:54 UTC
Dev Toolsevaluationupdated 08 Oct 2026

DefinitelyTyped review

DefinitelyTyped is the community repository behind npm's `@types` packages, which add TypeScript declarations to JavaScript libraries that do not ship their own. Most developers need one published package such as `@types/node`; the 288.6 MB monorepo is mainly for people reviewing or correcting those declarations.

-1stars / 7d
Verdict

Our 62,655-file DefinitelyTyped checkout rejected npm after 72 seconds because contributors must use pnpm, while ordinary users can skip the monorepo and install one @types package. Use those packages when a JavaScript dependency lacks declarations. If you own the library, ship its types beside the implementation; if you contribute here, test the real runtime and keep the change narrow.

We ran it

Lab card: what happened when we ran DefinitelyTypedScreenshot of DefinitelyTyped (github.com/DefinitelyTyped/DefinitelyTyped)
Install✗ · 72s
Build—
Repo62655 files~5,465,163 lines of source · 288.6 MB · 7 CI workflows

Answers from our run

Does DefinitelyTyped build from source?

The dependency install failed, and the project has no separate build step. We cloned commit d29d652 into a clean Debian container with 3 CPUs and no project-specific setup.

Who should not use DefinitelyTyped?

TypeScript library authors choosing where to publish new declarations: the README tells authors to bundle them with their own package.

What are the alternatives to DefinitelyTyped?

Bundled declarations, TypeScript DOM lib generator, tsd. Our 62,655-file DefinitelyTyped checkout rejected npm after 72 seconds because contributors must use pnpm, while ordinary users can skip the monorepo and install one @types package.

Setup2/5Consumer use is small; our 288.6 MB workspace install failed
Docs5/5Detailed package, testing, versioning, and review guidance
Community5/5Pushed October 8 with 557 open issues under active review
Maturity5/5Established npm publishing with owners and automated checks

Discussed on

  1. hnTypeScript types should be moved to DefinitelyTyped9 points
  2. hnTypeScript Definitions for Most Popular JS Libraries4 points

Who it’s for

TypeScript users whose JavaScript dependency does not include declaration files.
Library users correcting a type mismatch they have reproduced against the real package.
Definition owners willing to review changes for packages they actively use.
Maintainers moving an older JavaScript API into a typed codebase.

Who it’s NOT for

TypeScript library authors choosing where to publish new declarations: the README tells authors to bundle them with their own package.
Contributors who do not use the package they want to add: make-work definitions are rejected.
Coding agents preparing several pull requests: the policy permits one agent-authored PR and requires [auto-generated] in its title.
Projects pinned to old TypeScript releases without checking npm tags: current packages are tested only on TypeScript versions less than two years old.
Developers treating declaration checks as runtime proof: the package examples are type-checked, while the README separately tells authors to run real code.
Contributors using npm for the workspace: our npm install was rejected because the repository requires pnpm.

Setup reality

Our sandbox cloned commit d29d652, a 288.6 MB checkout with 62,655 files and about 5,465,163 source lines. npm install failed with exit 1 after 72 seconds. The log says, Use "pnpm install" for installation in this project, and identifies npx only-allow pnpm as the failed command. The run produced no build or test result.

Consumers normally avoid this workspace and install the single @types package they need. Contributors need Node, pnpm, a fork, and the upstream library they are describing. The README recommends a blobless clone and a filtered pnpm install when you are changing one definition family.

The repository is a pnpm workspace with 7 CI workflow files, no Dockerfile, and no tests directory at the root. Package checks run through root commands, and sample TypeScript is type-checked rather than executed. A contributor still has to run the real JavaScript separately and get review from definition owners or maintainers.

Most users need one package, not the 288.6 MB repository

DefinitelyTyped's 62,655-file checkout is the source and review queue behind npm's @types scope. If a JavaScript library lacks declarations, its users can install a matching package such as @types/node and gain compiler checks plus editor completion. Scoped names are flattened, so declarations for @babel/preset-env live under @types/babel__preset-env. Consumers should first inspect the original package for a types or typings entry, since bundled declarations make a second source unnecessary.

The repository has an exit path for packages that start shipping their own types. Contributors remove the old definition and publish a stub pointing users to the library. That keeps implementation and declarations on one release track. DefinitelyTyped remains useful when upstream cannot or will not own that work, but cloning the entire workspace into an application solves nothing.

What happened when we ran it

Our sandbox cloned commit d29d652 into an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. The checkout occupied 288.6 MB before installation, contained 62,655 files, and held about 5,465,163 lines of source. Our scan found 7 CI workflow files, a workspace monorepo, no Dockerfile, and no root tests directory.

The npm install stopped after 72 seconds with exit code 1. Its final lines told us to use pnpm install and named npx only-allow pnpm as the failed command. That message is specific enough to act on: npm is the wrong package manager for this contributor workspace. The log does not show a dependency defect or a missing Debian package, so we would not label it as either.

Because installation failed, our run has no build or test result. That leaves a clean boundary around the finding: commit d29d652 rejected the command our Node harness selected. The repository's own status badges may show upstream CI health, but they do not turn our failed local setup into a pass. A contributor following the current README should start with pnpm.

One agent-authored pull request is the stated limit

DefinitelyTyped permits a coding agent to submit 1 pull request only after the user confirms the definitions are for personal use. The title must include [auto-generated]. The same policy rejects searches for popular untyped npm packages followed by bulk submissions. That is unusually direct governance, and it gives maintainers a concrete reason to close definition work that has no real consumer behind it.

Each package directory combines declaration files, metadata, compiler configuration, and sample TypeScript. Those examples are type-checked; they do not execute the JavaScript library. The README tells authors of a new definition to build and run real code first. A declaration can satisfy TypeScript while promising a function, export shape, or return value that the runtime never supplies.

Definition owners are listed in package metadata and receive review requests from the bot. Popular packages require support from their owners plus maintainer sign-off, while new definitions receive manual review. With 557 open issues on October 8, 2026, a narrow patch with a matching test has a much clearer path than a broad rewrite.

Current packages cover less than 2 years of TypeScript

DefinitelyTyped tests current packages against TypeScript versions less than 2 years old. Older compiler releases may still have compatible npm tags, but the active declaration line can adopt newer syntax as that window moves. Teams supporting an old enterprise branch should pin TypeScript and @types together, then check the published tags before upgrading either side.

Package versions also need careful reading. The major and minor numbers track the JavaScript library, while the declaration package's patch number advances independently when types are fixed. Matching @types/foo@5.4.x to foo@5.4.x is meaningful; expecting their patch numbers to describe the same release is not.

The October 8 push matters more than the 2019 release

GitHub recorded a repository push on October 8, 2026, with 51,456 stars and 756 combined open issues and pull requests. A separate issue search returned 557 open issues. The latest GitHub release is version 0.1.450 from September 2019, but the README says the master branch is automatically published to individual npm packages. That old tag is therefore a poor maintenance signal for this project.

Use DefinitelyTyped as a consumer when the upstream package leaves a type-shaped hole in your project. Contributors should use the pnpm path, install only the relevant workspace slice, and prove the declaration against the matching runtime version. If you maintain the JavaScript library, bundling its declarations is the cleaner destination because code and types can change in the same release.

Alternatives

ProjectWhat it isPick it when
Bundled declarationsType definitions published inside the JavaScript library under the library's own version.pick this instead when you maintain the upstream package and can release declarations with its implementation.
TypeScript DOM lib generatorThe generator for web-platform declarations that ship in TypeScript's standard library.pick this instead when the missing API is part of a web standard rather than a third-party npm package.
tsdA tool for testing the type declarations published by your own package.pick this instead when you own a package's declarations and want focused type tests in that package.

Sources

  1. DefinitelyTyped README
  2. DefinitelyTyped repository facts
  3. DefinitelyTyped open issues
  4. DefinitelyTyped 0.1.450 release

More dev tools reviews

compose-samples · librepods · sqlmap · coucou · world-execute-me-dsh-pv · mcp-extensions · the whole board →