Building a Verified SPFx Factory Instead of Another Code Generator

A chatbot that emits an SPFx React snippet is not much of a product. It wraps scaffolding, produces plausible code, and leaves the hard part—whether the result actually works—to the user.

I built a small local alternative: an SPFx Factory that turns structured requirements into an official SharePoint Framework scaffold, an implementation task for Codex, and a bounded verification report.

Repository: https://github.com/vystartasv/spfx-factory

The factory boundary

The factory is deliberately local:

• Node 22 CLI
• Official spfx create scaffolding
• React webpart-react projects
• Codex execution only behind explicit --execute
• Verification only behind explicit --verify
• No tenant login, deployment, credentials, telemetry, browser automation, or Git operations inside generated tasks
• Static policy scanning for secrets, permissions, unsafe URLs, and unauthorized mutations

The default path is safe and boring. It validates a specification, creates the official scaffold, renders FACTORY_TASK.md, and performs policy checks. It does not silently install packages or run an agent.

Verification is the product boundary

The generated project is not accepted because an agent says “done”. The factory records separate stages:

1. official scaffold
2. Codex implementation
3. policy scan
4. dependency installation
5. explicit test script
6. build
7. package

Missing scripts.test fails verification. Project warnings fail verification even when the command exits zero. Optional package scripts are reported as skipped instead of being silently omitted.

Verification child processes receive a Node heap override of 8 GB through NODE_OPTIONS. Existing non-heap options are preserved; the host macOS memory configuration is not changed.

Writable web parts are explicit

Read-only remains the default. Writable generation requires "mode": "writable" and explicit positive create/read/update/delete intent.

The writable policy is not “disable security checks”. It allows only narrow typed SharePoint/PnP mutation patterns while continuing to reject secrets, permission requests, unsafe URL schemes, raw HTTP mutation patterns, and other unrelated operations.

Local writable verification uses deterministic adapters. That proves CRUD logic, validation, conflict/error handling, and UI behavior in the generated project. It does not prove tenant writes, SharePoint permissions, authentication, deployment, or production behavior.

Two independent writable samples passed the final local gate:

• Request Tracker — local create/list/update/delete, optimistic conflict handling, accessible delete confirmation
• Leave Request — local submit/list/update/remove, date validation, recoverable error states

Both passed test, build, package, and policy stages with zero project warnings.

The failures were useful

The first generated samples exposed exactly why a verification layer matters:

• missing explicit test scripts
• TypeScript warnings from dynamic SCSS access
• unsupported Array.includes under the scaffold target
• void and floating-promise lint failures
• defensive javascript: test literals triggering SPFx lint
• a negative-path Jest test that did not match the installed Jest behavior
• dependency peer/deprecation warnings from the current SPFx scaffold

Each discovered defect became either a factory gate, a generated-task rule, or a regression test. The factory became stricter instead of hiding the failures.

What this does not claim

This is not tenant-ready automation. Local success cannot establish:

• SharePoint runtime behavior
• tenant permissions
• authentication and identity behavior
• deployment readiness
• browser accessibility in a real workbench
• production data correctness

Those require a separate human-controlled tenant validation stage.

Run it locally

npm install
npm test
npm run build
npm run check

node lib/cli.js validate --spec specs/request-tracker.json
node lib/cli.js generate \
  --spec specs/request-tracker.json \
  --output ./out/request-tracker \
  --execute --verify

The final factory repository checks pass with 47 tests, TypeScript build, type check, and whitespace validation. The generated writable samples were verified separately and remain disposable local artifacts rather than committed tenant projects.

The useful lesson is simple: an agent producing code is easy. An agent-backed factory that refuses to call broken, unsafe, or unverifiable output complete is the actual engineering work.