fix: correct the install order, the husky feature and failure reporting - #14
Merged
Merged
Conversation
Cleanup edited the generated project's package.json after the package manager had already written the lockfile, so the two disagreed and `npm ci` failed in a fresh Canton project. Cleanup now rewrites the lockfile from the patched manifest, and only when it changed something. - EVM: the `husky` feature is real again. It was advertised in `--info`, in `--help` and in the wizard, but cleanup deleted the hook files and the dependencies whether you asked for it or not. Selecting it now keeps the hooks; deselecting it removes them as before. - Feature removal is data-driven for both stacks. Features declare their `paths`, `scripts` and `dependencies` in `config.ts`, so the file lists live in one place instead of being repeated in `cleanupFiles.ts`. - package.json is read once, guarded against a template that ships none, and written only when a value changed. Two read-modify-write passes became one, and an untouched manifest is no longer reformatted. - Only removed directories strip scripts now. A script that merely mentions a removed file, such as `markdownlint CLAUDE.md`, survives.
A failed interactive install printed its error but exited 0 and left the half-written project on disk, so a wrapper script could not tell success from failure. The three operation steps now call `abortInstall`, which removes the partial directory and sets the exit code. - `--info` gained a `modes` list per stack. It used to describe `default` as valid for EVM while the validator rejected it, which broke the documented discovery flow for agents. - `default` mode now resolves feature requirements the same way `custom` does, so a feature that depends on another can never be kept without it. - The multiselect used `&&` where the inverse of an "and" needs `||`, so unchecking one item would also uncheck any item sharing its label. - `cli.tsx` reads the stack flags through a returned result instead of inspecting the global exit code twice. - The interactive steps take the resolved `mode` and `features` from `app.tsx` instead of each recomputing them. The review screen now lists what actually gets installed.
The code carried a mix of loose line comments and none of them showed up in editor tooltips. Each one that was worth keeping is now jsdoc on the declaration it describes; the rest said what the code already says and are gone. No behavior change.
`FeatureName` was an alias for `string`, so every feature name written as
a string literal went unchecked. Renaming `subgraph` in `config.ts` left
`isFeatureSelected('subgraph', ...)` compiling happily while quietly
reporting the feature as deselected.
It is now the union of the keys in `stackDefinitions`, so a rename turns
every stale reference into a compile error. Two side effects:
- `isFeatureNameValid` became a type guard, so validated `--features`
input narrows from `string` to a feature name.
- `getFeatureEntries(stack)` replaces four `Object.entries` calls over the
feature map, each of which needed its own cast.
The union caught a real slip in the tests, which asked for the
non-existent canton features `counter` and `e2e`.
Cleanup ran after the install, so it had to repair the lockfile the package manager had just written. Running it first means the manifest is already pruned when the install starts: one dependency resolution instead of two, nothing installed only to be deleted, and a lockfile that matches by construction. The lockfile repair pass is gone. - One way to remove a dependency. Features declare `packages`, which the package manager uninstalls. The second field that hand-edited package.json existed only because the install always ran the template's `postinstall` script; that call now happens only when the script exists, so Canton can use the same field as EVM. - Cleanup is one code path for both stacks. The paths a stack always removes, where it stages replacement files, and whether it commits the scaffold are `StackConfig` fields, not `stack === 'canton'` branches. The baseline commit moved to its own operation, which runs last. - The three operation steps were the same component three times, down to a byte-identical progress block. They now share `StepProgress`, which owns the progress list, the error display and the failure path, so a new step cannot forget to report a failure. - Feature names are typed inside the config too, so a mistyped `requires` or `ifFeature` fails to compile instead of being skipped at runtime. - Validation reads the modes a stack accepts from the config, which is the same list `--info` publishes. - One place prints the JSON failure envelope, and the caller recognises an already-reported error by type instead of by reading the exit code.
`pnpm audit` reported 14 advisories. One of them reached people who install the package: ink pulls in ws 8.18.2, and the fix landed in 8.20.1. The other three are test tooling only. - Added pnpm overrides for ws, vite, postcss and nanoid. Each is a patch or minor bump inside the major its parent already asks for, so nothing changes but the fix. `pnpm audit` is clean. - The post-install screen linked with "here" and "the docs". Those labels say nothing on their own, and a terminal that cannot render a hyperlink shows only the label. They now name what they point at. - The readme screenshot had no alt text and no height, so it was invisible to a screen reader and shifted the page while loading.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
No related issue.
Cleanup edited the scaffolded project's package.json after the package manager had already written the lockfile, so a fresh project failed
npm ci. Fixing the order turned up more problems, so this is a full sweep: correctness first, then duplication, then a dependency audit.Changes
huskyfeature keeps the git hooks, instead of deleting them and the dependencies behind them--infopublishes the modes each stack accepts, and the validator reads that same listdefaultmode resolves feature requirements, which onlycustomdid beforepnpm auditis clean; one of the advisories reached everyone who installed the packageAcceptance criteria
npm ci/pnpm install --frozen-lockfilewith no further workTest plan
Automated tests
pnpm installpnpm lint,pnpm typecheck,pnpm test,pnpm buildandpnpm knippnpm auditand expect no known vulnerabilitiesManual verification
pnpm install && pnpm buildnode <repo>/dist/cli.js --evm --ni --name check_evm --mode custom --features demo,subgraph,typedoccheck_evmand runpnpm install --frozen-lockfile; expect it to succeed, andvocsand.huskyto be gonenode <repo>/dist/cli.js --canton --ni --name check_canton --mode defaultcheck_cantonand runnpm ci --dry-run; expect it to succeed, andgit logto show the baseline commitBreaking changes
EVM
fullmode now keeps the husky hooks, sincefullmeans every feature andhuskyis one. Delete.huskyin the generated project to get the old result.Checklist
Screenshots
None.