You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Narrowed after measurement. This card was originally filed as "neither scaffolder writes a lint script". Half of it has since been fixed in #16330: the blank template now declares "lint": "objectstack lint" and its CI workflow runs it. What is left is the parity half, which lives in a file outside that card's declared surface.
packages/cli/src/commands/init.ts — its three script maps (around lines 526, 617, 690) each declare dev, start, build, validate, typecheck. No lint.
So npm create objectstack and os create / os init now produce projects with different script sets, and only the first can run the CI workflow's pnpm lint step. A project scaffolded through init.ts that later copies the template's workflow gets a red build on a step whose script it does not have.
The question this closes is settled, so this is mechanical
Whether objectstack lint is clean on a freshly scaffolded blank project was the open risk when this card was first filed. It was measured for #16330 and the answer is yes: scaffolded for real from the repo-built scaffolder, npm install against the registry (@objectstack/cli 17.3.0), then npm run lint → exit 0, ✓ All checks passed. The severity-threshold question is likewise moot — no finding fires on the template's one object.
Why the script is worth having in both
objectstack lint is not a rename of objectstack validate. packages/cli/src/commands/validate.ts calls runAuthoringRules('validate', ...), so security-owd-unset is reachable from pnpm validate. But checkHookBodyLowering (packages/cli/src/lint/hook-body-lowering.ts) is imported by packages/cli/src/commands/lint.ts and by nothing else — git grep hook-body-lowering -- packages returns that import and the rule's own test. hook-body/not-lowerable is one of the two defects #16330 was filed about.
The ask
Add lint: 'objectstack lint' to each script map in packages/cli/src/commands/init.ts, positioned after validate to match the template.
Worth considering alongside it: the two scaffolders' script sets are held equal by nobody today, which is what let them diverge in one PR. A pin asserting init.ts's maps against the blank template's package.json would make the next divergence a red test rather than a discovery.
Not in this card
The template half — already done in #16330. Any lint rule change. Any change to os validate's rule set.
domain:*/ type / priority are triage's.Narrowed after measurement. This card was originally filed as "neither scaffolder writes a
lintscript". Half of it has since been fixed in #16330: the blank template now declares"lint": "objectstack lint"and its CI workflow runs it. What is left is the parity half, which lives in a file outside that card's declared surface.Measured
packages/create-objectstack/src/templates/blank/package.json— declaresdev,start,build,validate,lint,typecheck(as of scaffold:create-objectstackcreates.github/but ships no workflow, so every scaffolded app starts with zero CI — the gates exist as npm scripts nothing ever runs #16330).packages/cli/src/commands/init.ts— its three script maps (around lines 526, 617, 690) each declaredev,start,build,validate,typecheck. Nolint.So
npm create objectstackandos create/os initnow produce projects with different script sets, and only the first can run the CI workflow'spnpm lintstep. A project scaffolded throughinit.tsthat later copies the template's workflow gets a red build on a step whose script it does not have.The question this closes is settled, so this is mechanical
Whether
objectstack lintis clean on a freshly scaffolded blank project was the open risk when this card was first filed. It was measured for #16330 and the answer is yes: scaffolded for real from the repo-built scaffolder,npm installagainst the registry (@objectstack/cli17.3.0), thennpm run lint→ exit 0,✓ All checks passed. The severity-threshold question is likewise moot — no finding fires on the template's one object.Why the script is worth having in both
objectstack lintis not a rename ofobjectstack validate.packages/cli/src/commands/validate.tscallsrunAuthoringRules('validate', ...), sosecurity-owd-unsetis reachable frompnpm validate. ButcheckHookBodyLowering(packages/cli/src/lint/hook-body-lowering.ts) is imported bypackages/cli/src/commands/lint.tsand by nothing else —git grep hook-body-lowering -- packagesreturns that import and the rule's own test.hook-body/not-lowerableis one of the two defects #16330 was filed about.The ask
Add
lint: 'objectstack lint'to each script map inpackages/cli/src/commands/init.ts, positioned aftervalidateto match the template.Worth considering alongside it: the two scaffolders' script sets are held equal by nobody today, which is what let them diverge in one PR. A pin asserting
init.ts's maps against the blank template'spackage.jsonwould make the next divergence a red test rather than a discovery.Not in this card
The template half — already done in #16330. Any lint rule change. Any change to
os validate's rule set.