Getting started
Tapid is a JavaScript and TypeScript package manager written in Rust. The current client is an early, inspectable implementation, not a drop-in replacement for npm or pnpm.
The useful path today is a project with a validated manifest, a checked-in tapid.lock, and verified store content. Tapid validates those inputs before activating managed node_modules, then runs root scripts only when you explicitly ask it to.
Try the implemented path
From the Tapid repository, build the CLI and create the same consumer fixture used by the integration tests:
cargo build -p tapid --locked
export GITHUB_ENV="$(mktemp)"
node tests/fixtures/create_consumer_project.js
. "$GITHUB_ENV"
export TAPID_FIXTURE=1
target/debug/tapid install --offline --frozen --project-dir "$TAPID_FIXTURE_PROJECT"
target/debug/tapid run --project-dir "$TAPID_FIXTURE_PROJECT" test -- forwarded 0
The fixture checks managed node_modules, root-script execution, argument forwarding, child exit-code propagation, executable metadata, and suppression of dependency lifecycle scripts. Its empty package graph is a test boundary, not evidence of general package installation.
What the current client can answer
- Can this project replay its existing lockfile without network access?
- Does the lockfile's manifest and store content validate before activation?
- Were managed
node_modulesfiles created? - Can an explicit root script run with forwarded arguments?
- Does the child process exit code return to the caller?
- Were dependency lifecycle scripts suppressed during install?
The online registry path is deliberately constrained. Tapid requires registry metadata with the dependency and integrity information needed to construct a verified graph, and fails closed when those requirements are not met.
The command developers want next
This is the intended package-facing shape, but it is not accepted by the current CLI:
tapid install is-char
tapid i is-char
The current parser rejects the positional package name. Package-spec parsing, complete dependency resolution, lockfile generation, and the resulting package installation flow are still implementation work.
Run a project script
tapid run <script> reads a root package.json script, runs it in the project directory, prepends the managed node_modules/.bin directory to PATH, forwards arguments after --, and returns the child exit status.
tapid run dev
tapid run test -- --runInBand
Root scripts can execute arbitrary project code through the platform shell. This is compatibility-oriented process execution, not a sandbox.
Current status and direction
| Area | Status | What is true today |
|---|---|---|
| Manifest validation | Implemented | package.json identity is validated before project work. |
| Lockfile replay | Implemented | Offline and frozen replay require the lockfile and verified store inputs. |
| Node-compatible linking | Implemented | Managed package files and executable metadata are materialized for the supported path. |
| Root scripts | Implemented with constraints | Explicit tapid run works, but it is not sandboxed. |
| Package-spec installation | Not currently supported | tapid install is-char and tapid i is-char are planned CLI shapes. |
| Full npm compatibility | In progress | Semver edge cases, aliases, tags, peers, workspaces, and other behaviors remain incomplete. |
| Registry publishing and policy | Future direction | Registry services, provenance verification, policy enforcement, and agent integration are not current client guarantees. |
Continue with Commands for the actual CLI surface, then read Package identity and Evidence and policy for the models behind the next implementation work.