starknet.js: the JavaScript client library for Starknet, with a separate ledger build

What it is, and who maintains it

starknet.js is described simply as a JavaScript library for Starknet, and the project is the starknet-io one, with the copyright held by StarkWare for 2026 and the licence MIT. The README carries a powered by StarkWare badge, and the acknowledgements thank the StarkWare team for their dedicated support, alongside the original creator Sean, and people from Argent and SpaceShard. So this is the official client library for the Starknet ecosystem rather than a community wrapper, which is the main thing to establish before evaluating anything else about it. The documentation site is starknet-js.com, the topic list covers ethereum, l2, starknet, starkware, zk, zk-rollup and zk-starks, and the last push to the repository was on 2026-10-15, the same day as the v11.3.0 release.

Three npm channels, and the fact that they track three branches

The installation section offers three commands, and they are not three versions of the same thing. npm install starknet gives the latest official release from the main branch, npm install starknet@next gives the latest pre-release from the develop branch, and npm install starknet@beta gives the latest beta from the beta branch. The default branch of the repository is develop, so the published release comes from a different branch than the one you see when you browse the source. That is a common pattern for libraries that want a stable release while development continues, but it means the code you read on GitHub is often newer than the code you install. The releases are v11.1.0 on 2026-10-06, v11.2.0 on 2026-10-12 and v11.3.0 on 2026-10-15, so the minor line is moving every few days.

# latest official release (main branch)
$ npm install starknet

# or for latest pre-release version (develop branch)
$ npm install starknet@next

# or for latest beta release version (beta branch)
$ npm install starknet@beta

The export map, and why a separate ledger entry point exists

The package manifest is where the interesting structural decision shows. The main entry is the root export, with a CommonJS build at dist/index.js, an ES module build at dist/index.mjs, type declarations, and a browser global build at dist/index.global.js served through both jsdelivr and unpkg. But there is a second entry point, ./ledger, with its own types, import and require paths, and the package declares a typesVersions entry for it as well. The ledger subpath is the piece that distinguishes this library from a general JSON-RPC client, because the ledger pieces are the ones that have to work inside a Cairo execution environment, and bundling them with the Node-oriented client code would pull dependencies into a context that cannot take them. The build produces the shapes separately for that reason, with tsup invoked once for the main build and then again for the esm, iife and dts variants.

The agent skill, and a candid admission about model training data

There is a section on using AI, and it is unusually direct about a real problem. AI training data about starknet.js is often outdated, so to give an AI coding agent accurate and up to date guidance, the project ships an official skill in the skills/starknet-js/ directory of the repository. It works with Claude Code, Codex, Cursor, Gemini CLI and any other agent supporting the open Agent Skills standard, and you install it with npx skills add starknet-io/starknet.js. Alternatively you can copy the skill files directly, with a curl command that pulls SKILL.md, calldata.md and interacting.md into a skills directory, and the README notes that the command installs into Claude Code's skills folder so you should adapt the target directory for other agents. This is a sensible response to a genuine problem. A library that ships a skill for assistants is telling you that the model's memory of it is probably out of date, which is usually true of any fast moving client library.

npx skills add starknet-io/starknet.js

How the build and test pipeline is put together

The scripts in the package manifest describe the workflow. The build runs tsup and then the esm, iife and dts builds, and the prepare script runs the build and then husky, so a fresh clone has a working dist and the git hooks in place. The test setup is Jest with a separate unit configuration in jest.unit.config.ts and a top level jest.config.ts, and the test script runs in band with --detectOpenHandles, which is the standard way to run a suite that opens sockets without hanging the run. The pretest step is lint plus a TypeScript check, so type errors and lint failures are caught before the suite runs, and the posttest step runs the formatter. There is also a __mocks__/ directory, a __tests__/ directory, and a scripts/ directory. The docs have their own build, with the docs script changing into the www directory and a docs:build variant that passes a git revision override so the version is baked into the generated site.

The documentation, and the workshop

The documentation is split into guides and an API reference, hosted on the starknet-io GitHub Pages site, with a separate API reference for the library. Alongside it there is a workshop repository by Philippe ROSTAN for playing with code examples, and the acknowledgements thank him by name, along with a link to the workshop. So the learning material is not just the reference, there is a hands-on path for TypeScript specifically. The repository also carries a www/ directory, which is the source of the documentation site, and its own build commands separate from the library build, which is the usual arrangement for a library that maintains a site alongside its package.

Contributing, funding and the state of the project

The contribution path is the conventional one, read CONTRIBUTING.md first, and there is a dedicated channel for the library on the Starknet Discord, which is the right place to raise a question about this specific client rather than the protocol. The repository carries a CODE_OF_CONDUCT.md, a SECURITY.md, a FUNDING.json, an AGENTS.md, a CHANGELOG.md and a .husky/ directory, and the tooling is a .eslintrc with a .eslintignore, a .prettierrc, a .commitlintrc and a .releaserc.mjs, so releases are automated through semantic-release and commits are linted. The last push was on 2026-10-15, the default branch is develop, the repository is not archived, and the primary language is TypeScript. The package is published with only the CHANGELOG.md and the dist directory in the tarball, which keeps the install small.

Editorial conclusion

starknet.js suits a JavaScript or TypeScript application that needs to talk to a Starknet node, to build and submit transactions and to read contract state, and that wants an official client rather than a hand rolled JSON-RPC layer. It is the wrong choice for a Cairo contract, since the library is for the client side, and a poor fit if you need the package to work identically in a CommonJS and a modern ESM project without a bundler, since the exports map offers both but the build pipeline produces several artefact shapes. Before adopting it, decide which channel you want, because the three npm tags track three branches, and note that the maintainers say AI training data about the library is often outdated, which is a real reason to use the shipped skill rather than a model's memory.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. starknet-io/starknet.js on GitHub