Getting started
Install Tapid from the public release, run a supported package flow, and inspect the result.
Install Tapid from the public release installer, then use it in a normal package.json project. The installer finds the latest stable GitHub release, verifies the archive against its SHA256SUMS entry, and stages the binary before replacing an existing installation.
Install Tapid
macOS and Linux
The Unix installer places Tapid in ~/.local/bin and adds that directory to PATH when needed. Open a new terminal if another process does not see the change, then check the installed version:
Windows PowerShell
The PowerShell installer places Tapid in $HOME\.local\bin and updates your user PATH when needed. Open a new PowerShell window if another process does not see the change, then check the installed version:
The latest release page also lists every native archive, SHA256SUMS, and the release notes fetched from GitHub during the website build.
Install a package
Create a project and install one supported package:
tapid i <package> is an alias for tapid install <package>. The command adds the dependency to package.json, resolves supported transitive dependencies, checks registry-declared integrity, writes tapid.lock, stores the verified package tree, and activates managed node_modules. Dependency lifecycle scripts stay disabled.
An explicit --allow-unverified-registry-artifacts compatibility exception can accept locally computed artifact integrity for an online install. It emits a warning, cannot be combined with --offline or --frozen, and produces provenance that frozen replay rejects. See the install command before using it.
Run tapid install in an existing project to resolve its declared dependencies. Once the lockfile and verified store are present, replay the same graph without changing the lockfile:
Offline frozen replay checks the manifest, lockfile, and stored package data before activation. It does not resolve the graph again.
What Tapid checks
Tapid keeps the familiar package.json and registry workflow, but records more of the install boundary. During an online install it requires registry metadata to declare the SHA-512 used for the package archive. It records the exact registry, version, artifact digest, and dependency edges in tapid.lock, then materializes managed node_modules only after those inputs validate.
What the current client can answer
- Which exact package versions and dependency edges were selected?
- Did registry metadata declare the integrity used to authenticate each artifact?
- Does the lockfile's manifest and verified 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 installation?
The default online registry path fails closed when required metadata or declared integrity is missing. JSR support remains experimental and fails closed unless metadata supplies an HTTPS npm artifact and valid SHA-512 integrity.
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.
Root scripts can execute arbitrary project code through the platform shell. This is compatibility-oriented process execution, not a sandbox.
Current status and direction
- Manifest validation
- Implemented
package.jsonidentity is validated before project work. - Lockfile replay
- ImplementedOffline and frozen replay require the lockfile and verified store inputs.
- Node-compatible linking
- ImplementedManaged package files and executable metadata are materialized for the supported path.
- Root scripts
- Implemented with constraintsExplicit
tapid runworks, but it is not sandboxed. - Package-spec installation
- Implemented with constraints
tapid install is-charandtapid i is-charadd and install supported npm packages. - Full npm compatibility
- In progressTags, aliases, peers, workspaces, private registry authentication, and several semver and optional-dependency behaviors remain incomplete.
- Stable release installation
- AvailableThe public installer selects a stable GitHub release, verifies its archive checksum, and stages the binary before replacement.
- Registry publishing and policy
- Future directionRegistry services, provenance verification, policy enforcement, and agent integration are not current client guarantees.
Continue with Commands for the CLI surface, or read Contributor if you are changing Tapid itself.