Installation
Detailed background for this page
Detailed background for this page
Make a new Jeston workspace reproducible before writing application code.Expected outcome. A clean install that another contributor can repeat on a supported Node runtime.Why this boundary matters. Most early framework friction comes from drift in Node versions, package managers, environment variables, and generated artifacts.
Page-specific implementation notes
- Pin the runtime: Choose the Node version used by CI and local development.
- Install the package: Keep the framework dependency explicit and inspect the lockfile.
- Run the first checks: Verify typecheck, tests, build, and package contents before customization.
- Record assumptions: Document environment variables, scripts, and the expected directory shape.
Page-specific failure questions
- What belongs in source control?: Source, lockfile, scripts, configuration examples, and documentation; never credentials.
- What should fail early?: Unsupported Node versions, missing environment variables, and broken package exports.
- What should the first commit prove?: That a clean checkout can install, typecheck, test, build, and start.
Start · Installation
Page focus — Make a new Jeston workspace reproducible before writing application code.
Installation
Start · Installation
Purpose — Make a new Jeston workspace reproducible before writing application code.A clean install that another contributor can repeat on a supported Node runtime.
At a glanceKey concepts
This page is intentionally focused on one boundary. Use the decision table and implementation sequence below as a working review sheet, not as a generic framework overview.
Runtime
Node 20 or newer
Verification
typecheck, test, build
Reproducibility
lockfile and scripts
What to verify
Working example
This guide has its own decision surface. Use the visual blocks for orientation, then open the detailed background above when you need the longer explanation.
Before you move on
Most early framework friction comes from drift in Node versions, package managers, environment variables, and generated artifacts.Implementation notes
Decision lens
Related topics
- rocket · Build the first app — Read the focused guide for this boundary.
- terminal · Inspect the CLI — Read the focused guide for this boundary.
- circle-check · Prepare release checks — Read the focused guide for this boundary.
References
Pin the runtime
Choose the Node version used by CI and local development.
Install the package
Keep the framework dependency explicit and inspect the lockfile.
Run the first checks
Verify typecheck, tests, build, and package contents before customization.
Record assumptions
Document environment variables, scripts, and the expected directory shape.
Choose a working mode
- npm
- CI
- Restricted network
Use the published package and commit the lockfile.
Decision table
Design note A fast first request is less valuable than a repeatable first request.
Do not add Vite, Express, or a second application runtime to the Jeston setup.
Questions worth answering
What belongs in source control?
What belongs in source control?
Source, lockfile, scripts, configuration examples, and documentation; never credentials.
What should fail early?
What should fail early?
Unsupported Node versions, missing environment variables, and broken package exports.
What should the first commit prove?
What should the first commit prove?
That a clean checkout can install, typecheck, test, build, and start.
Continue with a related guide
Build the first app
Open the related guide when this page leaves a boundary unresolved.
Inspect the CLI
Open the related guide when this page leaves a boundary unresolved.
Prepare release checks
Open the related guide when this page leaves a boundary unresolved.
This page is complete when its specific decision is documented, its failure behavior is tested, and its operational signal has an owner.