fix(init): refuse to overwrite files when scaffolding into the current directory - #3985
Conversation
…t directory Without a project name, `veryfront init` scaffolds into the working directory (the non-interactive default: piped stdin, CI, `--template` with no name). `createProject` only checked for conflicts when a name was given, so an existing `package.json`, `README.md`, or any other file the template ships was silently replaced, with no `--force` and a "Project ready" banner. The current-directory path now refuses when any file the scaffold would write already exists, naming every conflicting file and pointing at `--force`. `.gitignore` is merged rather than replaced and so is never a conflict; an empty directory, or one holding unrelated files, scaffolds as before. Regression tests cover the refusal, the message, the empty and unrelated-file cases, `--force`, and the CLI path through `initCommand`. The API reference pins for `cli/shared/project-creation.ts` are regenerated with CI's Deno.
|
Warning Review limit reached
Next review available in: 17 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
📦 Client bundle boundary
A server module in a client graph aborts hydration in the browser. New leaks fail CI; known leaks are tracked in |
main added the named-directory refusal test from #3983 in the same place this branch adds the current-directory refusal test. Both describes are kept: they cover different paths through initCommand.
`--force` now also overwrites files the scaffold would write into the current directory, so "Overwrite existing directory" no longer describes the whole flag. The help line and the InitOptions doc comment both say files and directories.
`scaffoldWritePaths` is a hand-maintained mirror of the writes in `createProject`. A new write added without a matching entry silently narrows the guard, and every existing test still passes because they each name one or two files. The new test scaffolds with the deno runtime and an integration, which is the widest write set (template files, package.json, deno.json, .env, .env.example), then runs again over that directory and requires every created path back in the refusal. Dropping deno.json or the env files from the mirror turns it red and leaves the other four tests green.
2 participants
Summary
veryfront initscaffolds into the working directory (the documented non-interactive default: piped stdin, CI,--templatewith no name).createProjectonly checked for conflicts when a name was given, so an existingpackage.json(with the author's scripts),README.md, or any other file the template ships was silently replaced — no--force, exit 0, "✓ Project ready".--force:.gitignoreis merged rather than replaced, so it is never a conflict. An empty directory, or one holding unrelated files, scaffolds exactly as before.--forcekeeps overwriting.docs/api-reference/veryfront/scaffold.mdline pins regenerated with CI's pinned Deno 2.7.7 (only that file changed).Found by the
vf-dx-dogfoodedge-case pass against publishedveryfront@0.1.1251.Test plan
createProjectconflict tests + 1initCommandtest failed on main (no rejection); the empty-dir and--forcetests passed on main and still pass (behaviour preserved)cli/commands/init/,cli/shared/project-creation.test.ts,cli/app/operations/project-creation.test.ts(15 files, 177 steps) pass--force→ overwritten; empty cwd → scaffoldeddeno lint,deno fmt --check,lint:anti-slop,lint:sanitizer-baseline,lint:test-typecheck,docs:api-reference:checkcleanUpdate
origin/main. fix(init): exit non-zero when the target directory already exists #3983 landed adescribe("initCommand target directory")block in the sameplace this branch adds
describe("initCommand into the current directory"). Both are kept: theycover different paths through
initCommand(a named target directory, and the current directory).--forcehelp copy now reads "Overwrite existing files and directories". The flag no longer onlyoverwrites a directory, so the old line described half of it.
scaffoldWritePathsis a hand-maintained mirror of the writes increateProject,and every other test names only one or two files, so a write added without a matching mirror entry
would narrow the guard with the suite still green. The new test scaffolds with the deno runtime and
an integration (the widest write set: template files,
package.json,deno.json,.env,.env.example), runs again over that directory, and requires every created path back in therefusal. Dropping
deno.jsonor the env files from the mirror turns it red and leaves the otherfour green.