npm and Installed Sources
A Hosanna app uses npm for project tooling and ordinary JavaScript dependencies, but the licensed framework and compiler are not consumed as a normal runtime npm package.
Distribution Roles
| Dependency | Distribution and role |
|---|---|
@tantawowa/hosanna-tools | npm development dependency that provides the project-local hst CLI and testing API |
@tantawowa/hosanna-eslint-plugin | npm development dependency for Hosanna-specific lint rules |
| Hosanna UI SDK | License-gated or configured source installed into the app-local hosanna-ui/ directory |
| Hosanna Compiler | Versioned executable installed to bin/hsc from the hosanna.json compiler pin |
| Generated source | Project output under src-generated/; not a package to install manually |
Imports such as @hs-src/... and @hs-generated/... are TypeScript path aliases into installed or generated project source. They are not package names to add with npm.
Clean Install
Use the committed lockfile:
npm ci
Then authorize and install the versions configured by the application:
npx hst license:status
npx hst sdk:install
npx hst compiler:install
Keep HSC_LICENSE_KEY in a protected environment variable or secure local store. Do not put it in package.json, .npmrc, a command argument, or CI logs.
Inspect the Active Toolchain
node -p "require('./package.json').engines?.node"
npx hst version
npx hst config show
npx hst compiler:status
The current hosanna-ui-samples-public lockfile pins Hosanna Tools and declares its supported Node range. Treat those checked-in values—not a version copied into a guide—as authoritative for that checkout.
Always run npx hst or an npm script so the repository-local CLI wins over a different global installation.
For source and compiler installation details, see Hosanna Compiler License And Tool Setup.