chore: remove unused files - #475
Merged
Merged
Conversation
kojiwakayama
added a commit
that referenced
this pull request
Aug 11, 2026
…uessed The starter templates ship as data at `esm/cli/templates/manifest.js`, but that path was not an exported subpath. The only way in from outside was to resolve `veryfront/cli` and hop a relative file URL to it - routing around the `exports` map, which exists to stop exactly that. That made the coupling undeclared, and undeclared is the part that bites: if this repository changed its build output layout, the consumer would break at runtime and nothing here would fail, because nothing here knew anyone depended on the path. It is the same shape as issue #475 itself - an unversioned, unenforced dependency between two repositories - one size down. `veryfront/cli/templates/manifest` is the declared name that replaces the guess. It is a thin re-export, so the manifest is still emitted once; the wrapper adds a `TemplateManifest` type in place of the 26KB literal type dnt infers from the JSON. `loader.ts` now reads the manifest through the same module, so the CLI and external consumers cannot end up with different views of it. The module cannot be called `manifest.ts`: dnt compiles `manifest.json` to `manifest.js` beside it and the two would emit over each other, which `manifest-export.test.ts` also pins. Enforcement, in the repository where a layout change originates: - `cli/templates/manifest-export.test.ts` fails if the subpath stops being declared, if it starts compiling over the JSON module, or if the manifest stops carrying every starter with a non-empty files map. - `npm-install-smoke.sh` step 6 imports the bare specifier from a clean-room install, so Node resolves it through the published `exports` map. The deep `node_modules/veryfront/esm/...` paths the other steps use bypass that map, so this is the only step that can catch the export going missing; without the entry it fails with ERR_PACKAGE_PATH_NOT_EXPORTED. The API-reference generator reported the new default export as `default` and emitted `import { default } from ...`, which does not compile. It now renders a default export as a default binding, covered in generate-api-reference.test.ts. tsconfig.json carries the matching paths entry: Bun resolves root aliases natively through it, and tsconfig-paths-parity.test.ts fails when it and the deno.json import map disagree.
kojiwakayama
added a commit
that referenced
this pull request
Aug 11, 2026
…ne artifact A new project is supposed to install, run and build with zero errors and zero lint errors (veryfront-issue-inbox #475). Three of the seven starters did not: agentic-workflow 6 tsc errors, 5 lint errors coding-agent 4 tsc errors multi-agent-system 1 tsc error, 1 lint error saas-starter 3 lint errors The worst was `agentic-workflow`. Its `publish` step passed an `execute` callback, which `StepOptions` does not accept: `tsc` rejected the object literal and `step()` throws "must specify either 'agent' or 'tool'" the moment the workflow runs, so the template's headline feature could never execute. That step now calls a real `tools/publish.ts`, and the run view renders `run.nodeStates` — the field `WorkflowRun` actually has — instead of a `steps` array that only the demo API invented. The rest were ordinary defects nobody could see: `readDir` streams entries but `list-files` filtered it like an array; `getAgentsAsTools` takes a description map, not a list of ids; four `async` callbacks never awaited anything; three `<button>`s had no `type`. None of this was caught because the templates are real files that the repo's own lint and typecheck never look at. `cli/templates/scaffold-quality.test.ts` closes that: it scaffolds every starter the way `veryfront init` does and runs the same `deno lint` that `veryfront lint` shells out to, expecting silence. It fails on the three templates above before this change. The second half of #475 is that a project created in Studio must be identical to one created by the CLI. It could not be: the hosted flow copies a stored project row, which has no repo, no lint gate and no link to the release train, so it froze at the pages-router era while these templates moved on. This adds the artifact that makes one source possible — `veryfront/scaffold` exports `materializeScaffold()`, which returns the complete contents of a new project without touching a disk, and maps Studio's `blank` slug onto the CLI's `minimal` starter. `createProject` now assembles through the same function it exposes, so the two cannot disagree, and `scaffold-parity.test.ts` proves it by diffing a really-scaffolded directory against the materializer's output for every template rather than against a snapshot a future template change would silently invalidate. Consuming it from veryfront-api, and retiring the DB 'blank' row, is the follow-up this unblocks.
kojiwakayama
added a commit
that referenced
this pull request
Aug 11, 2026
…olds it Rebased onto the `cli/templates/` -> `templates/` move (#3596). `./scaffold` keeps its name - it names the capability, not the directory - and now points at `./templates/scaffold.ts`. The second export this branch declared, `./cli/templates/manifest`, is gone. The manifest is data; `materializeScaffold()` is the behaviour. A consumer reading the manifest has to reimplement package.json generation, AGENTS.md injection and .gitignore for itself - a second scaffolder fed from one data source, which is issue #475 one level down. veryfront-api will call `materializeScaffold()`, and nothing in this repository or its siblings reads the raw manifest, so the export had no consumer to keep. Nothing is published yet, so no name was burned. The enforcement stays, retargeted: - `templates/scaffold-export.test.ts` fails if `./scaffold` stops being declared, if it points at a file that no longer exists - the exact failure the directory move would have caused - or if the module stops exporting the behaviour a caller imports it for. - `npm-install-smoke.sh` step 6 imports the bare specifier from a clean-room install and materializes a project through it, so Node resolves it against the published `exports` map. The deep `node_modules/veryfront/esm/...` paths the other steps use bypass that map, so this is the only step that can catch the export going missing; without the entry it fails with ERR_PACKAGE_PATH_NOT_EXPORTED. `scaffold-quality.test.ts` reached the repo config through `../../deno.json`, which resolves above the repository now that the file sits one level higher; every template's type-check step failed on the missing config until it was repointed at `../deno.json`.
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
1 participant
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.
Description
Related Issue(s)
Type of Change
Checklist