Skip to content

Feat/continuum hardening#35

Open
evens-stone wants to merge 10 commits into
mainfrom
feat/continuum-hardening
Open

Feat/continuum hardening#35
evens-stone wants to merge 10 commits into
mainfrom
feat/continuum-hardening

Conversation

@evens-stone

@evens-stone evens-stone commented Jul 19, 2026

Copy link
Copy Markdown
Contributor

Description

Please provide a short summary of the changes you have made in this pull request. Include any context or background that might be helpful to reviewers.

Related Issue

Fixes # (issue number)

Type of Change

  • Bug fix
  • New feature
  • Documentation update
  • Refactoring
  • Other (please describe):

Checklist (Preconditions for Code Review)

  • Lint your code to ensure it adheres to the project's style guidelines.
  • Run all existing and new unit tests locally to verify correctness.
  • Ensure code changes are covered with appropriate tests (unit, integration, etc.).
  • Update all dependencies to their latest compatible versions.
  • Update documentation where necessary to reflect the changes.
  • Resolve all linting and compilation errors.
  • Follow SOLID principles and other best practices in the code.
  • Review the code for potential security vulnerabilities.
  • Add comments for complex or hard-to-understand parts of the code.
  • Ensure the PR is appropriately scoped (small, focused, and easy to review).
  • Ensure commit messages adhere to the Conventional commit message guidelines.
  • Add tests for any new features or bug fixes.
  • Clearly indicate if the pull request introduces any breaking changes.

Screenshots (if applicable)

Please add screenshots to help explain your changes if applicable.

Additional Information

Please provide any additional information that might be helpful during the review process.

claude and others added 10 commits July 18, 2026 00:42
@claude
feat(cli): static-asset aliases, premium output, full SSG (build --ss…
0858835 
…g), preview fix

- builder.assets ({ dir, aliases }) + builder.public config; @img/@css/@fonts/@styles/@assets
  resolve via Vite resolve.alias (dev, build, client and SSR)
- StoneReporter: signature banner, timestamped steps, elapsed-time success, summaries
- SSG end-to-end: 'stone build --ssg' (or rendering: 'ssg') runs the SSR build then
  pre-renders configured routes (stone.builder.ssg.routes, default ['/']) to
  dist/<route>/index.html by crawling the freshly-built server; orchestrated by ssg.ts.
  Validated end-to-end: dist/index.html contains pre-rendered markup + head + snapshot
- fix: preview resolves the same output as the build default (server.mjs)
- build: dts step excludes its own prior output (robust incremental type bundling)

New files lint-clean; pre-existing lint debt untracked separately. tsc + 273 tests green.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@evens-stone @claude
feat(cli): modern dev-server flow, robust process mgmt, complete Babe…
01a7d36 
…l toolchain (0.8.0)

declare the full Babel toolchain the generated builds invoke — @babel/core,
preset-env, preset-typescript, plugin-proposal-decorators (2023-11) and, crucially,
the class-properties/class-static-block/private-methods transforms — as real
dependencies (they were only resolved via workspace hoisting and would vanish on a
standalone install). Wiring the class-feature transforms explicitly into both the
Rollup (backend) and Vite (frontend) Babel configs makes static properties/methods,
static blocks and private members lower deterministically across ES5/ES6 targets,
independent of the runtime's native class-feature support.

rework the dev server around a supervised child process and context-aware output:
- new ProcessManager: restart waits for the old child to exit before respawning
  (kills the EADDRINUSE port race), SIGKILL fallback, single SIGINT/SIGTERM teardown
- ServeCommand: branded banner + build spinner on first launch; a concise
  "changed → rebuilt · restarted" line on live reload; backend keeps watching if the
  server self-exits, react mirrors the child exit code
- ServerBuilder.watchFiles: debounced, and scoped to the source root + config files
  instead of the whole working tree
- fix setupProcessSignalHandlers (took the child by value = always undefined) to read
  a getter at signal time, so Ctrl+C actually tears the child down

harden SSG: a build against an app without an HTTP adapter now fails fast with a clear,
actionable error (and, via the adapter exit-code fix, a non-zero exit) instead of an
8s wait then a swallowed ECONNREFUSED.

- bump to 0.8.0, sideEffects:false, internal deps as workspace:*
- 296 tests, 100% coverage; StoneReporter/ProcessManager/ServeCommand fully covered

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@evens-stone @claude
fix(cli): typedoc documents src only (build no longer type-checks tests)
8c87b18 
typedoc pointed at tsconfig.json (which includes tests/), so the doc step type-checked
test files and failed the build on their strict-TS violations. Point it at
tsconfig.build.json (src only). Unblocks the CLI build; the whole monorepo now builds.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@evens-stone @claude
style(cli): clear ts-standard debt in src (return-await, strict-boole…
e7a54a3 
…an, no-throw-literal)

Auto-fixed the 23 pre-existing ts-standard violations in src/. Build green (0 errors),
296 tests pass.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@evens-stone @claude
chore(cli): raise build heap for dts bundling (avoid CI OOM)
668ae31 
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@evens-stone @claude
feat(cli): extensible starter-plugin contract (open/closed, config-dr…
44597b9 
…iven)

Starters are no longer hard-coded in the CLI. New src/create/StarterContract.ts defines:
- Starter / StarterProvider / StarterSource (git | local | npm | custom) contracts.
- officialStarterProvider: the maintained set, mapped to git sources on the (configurable)
  starters repo — the default provider.
- registry: resolveStarterProviders (reads stone.createApp.starters, defaults to official),
  listStarters, findStarter, materializeStarter (git/local/custom; npm reserved).

Third parties publish a package exposing a StarterProvider and add it to
`stone.createApp.starters` — their starters then appear in `stone init` with no CLI change.
Questionnaire lists from the registry; CloneStarterMiddleware materialises via the chosen
starter's own source. Deleted the hard-coded templates.ts (+ its spec).

309 tests, 100% coverage, lint clean, build green.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@evens-stone @claude
refactor(cli): make the CLI fully starter-agnostic (link + manifest c…
4790b4d 
…ontract)

The CLI no longer bakes in any starter (not even ours). It knows only:
- a built-in DEFAULT link (`github:stone-foundation/stone-js-starters`) — just a link;
- how to fetch a link (git | npm | local) and read the starter's OWN contract,
  declared in its package.json `stone.starters` (fallback: whole package = one starter);
- `--starters link1,link2` (alias -s) to override/add starter links;
- auto-detection: installed packages declaring `stone.starters` show up with zero config.

StarterContract.ts rewritten around links/manifests: parseStarterLink, fetchStarter,
readStarterEntries, collectStarters, autodetectStarters, getAvailableStarters (memoised),
materializeStarter. Provider/template hard-coding removed. Questionnaire lists from
getAvailableStarters; CloneStarterMiddleware materialises the chosen (or first) starter.
`stone.createApp.starters` is now `string[]` (links).

Premium, decoupled, plug-and-play — starters evolve independently of the CLI.
321 tests, 100% coverage, lint clean, build green.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@evens-stone @claude
test(cli): await async process.exit in SIGINT test (no unhandled error)
7097475 
The SIGINT handler exits via stop().finally(() => process.exit(0)); the test restored the
process.exit spy before that microtask ran, so the real process.exit fired afterwards and
vitest flagged an unhandled error, failing the run. Await the exit within the mocked scope.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@evens-stone @claude
feat(create): derive vanilla JavaScript projects from the TypeScript …
13d66ea 
…templates

Stone.js is a TypeScript AND JavaScript framework. Rather than maintaining a
second set of templates, the JS variant is DERIVED from the TS one: types are
stripped while TC39 stage-3 decorators are preserved (target ESNext, no
experimentalDecorators), keeping the declarative and imperative APIs available
1:1 in both languages.

- add create/vanilla.ts (toVanillaSource/collectTsFiles/deriveVanilla)
- wire ConvertToVanillaMiddleware into the create pipeline (typing === 'vanilla')
- real (non-mocked) tests asserting decorator preservation + type stripping
- CLI coverage stays at 100%

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@evens-stone @claude
fix(create): correct scaffolder defaults — real template + TypeScript…
5c0ca52 
…-first

- default template 'basic' (which no longer exists) -> 'basic-service-declarative',
  so 'stone init --yes' resolves a real starter instead of falling back
- default typing 'vanilla' -> 'typescript': TypeScript is the source of truth;
  the JS variant is derived on demand (--typing vanilla). Also list TypeScript
  first in the interactive prompt.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@evens-stone evens-stone self-assigned this Jul 19, 2026
@evens-stone evens-stone added the enhancement New feature or request label Jul 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@evens-stone evens-stone

Labels

enhancement New feature or request

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@evens-stone @claude