finding(create-plugin): the scaffolder emits a per-package vitest test block — the shape objectui#3240 just removed from this repo

[claude]

Found while implementing objectui#3240 (PR #7523), which deletes every per-package vitest.config.* and closes the route Vitest takes when a directory has none — it falls back to that directory's vite.config.*. Every packages/PKG/vite.config.ts now calls assertCanonicalVitestInvocation, gated on process.env.VITEST.

@object-ui/create-plugin scaffolds the shape that route exists to refuse. packages/create-plugin/src/templates.ts emits, for a new plugin:

• a vite.config.ts carrying a test block (globals, environment, setupFiles: [./vitest.setup.ts]),
• a vitest.setup.ts, and
• "test": "vitest run" in the manifest.

For the scaffolder's actual audience — someone building a plugin in their OWN repo — that output is correct and should not change. The gap is narrower: a plugin scaffolded into this monorepo lands as a workspace package whose test entry is a package-cwd vitest run against a divergent local config, with nothing to refuse it. That is exactly the class objectui#5406 and objectui#3240 spent two cards closing, arriving through the scaffolder.

⚠️ Not measured: whether anyone has ever scaffolded into this repo, and whether the generated test script would actually go green or loudly red. Filed as an observation, not a diagnosis.

Possible shapes (not a recommendation — this needs triage):

• teach the scaffolder to detect an in-repo target and emit the repo's canonical vitest run --root ../.. packages/PKG/ form instead;
• or add the generated config to whatever the in-repo guard walk covers, so a scaffolded package fails the pin rather than the reviewer;
• or decide the in-repo case is out of scope and say so where the templates are defined.

⛔ Deliberately not fixed in PR #7523: changing the scaffolder's published output is a different blast radius from unifying this repo's own configs.

---

Generated by Claude Code