spfx-assurance: Offline Release Checks for SharePoint Framework Projects

Creating an SPFx web part is usually not the difficult part. The expensive failures happen later: invalid manifests, duplicated component IDs, unsafe URLs, committed secrets, missing tenant approval signals, or a build that only fails after someone starts a release.

I built spfx-assurance as a small, offline CLI for checking an existing SharePoint Framework project before release.

Usage

npx spfx-assurance check . --json assurance.json --md assurance.md --fail-on blocked

The MVP checks:

• package and SPFx metadata;
• Node engine mismatch;
• solution metadata and four-part version;
• component manifest shape and duplicate IDs;
• secret-shaped assignments;
• unsafe URL schemes at obvious sinks;
• non-local HTTP URLs;
• webApiPermissionRequests requiring tenant admin approval;
• configured build/test commands.

Reports contain stable verified, warning, blocked, and skipped statuses, plus a mandatory scope declaration:

Local verification only. This is not tenant validation, App Catalog approval, or a security audit.

That boundary is deliberate. A local tool cannot prove tenant permissions, App Catalog approval, deployment behavior, or every security property.

Safety choices

Configured commands are argv arrays rather than shell strings. Executables are allow-listed, shell: false is used, destructive-looking arguments are rejected, and report output cannot be written inside the inspected project.

The tool makes no network calls, accepts no credentials, and does not modify the project being inspected.

Why this exists

PnPjs, the Microsoft 365 CLI, SPFx Toolkit, and the PnP sample ecosystem already cover platform access, scaffolding, deployment, and reusable components. This project targets the missing handoff between “the code exists” and “the change is supported by evidence.”

The first release includes clean and deliberately broken SPFx-shaped fixtures, deterministic tests, a GitHub Actions workflow, JSON/Markdown reports, and explicit limitations.

Verified locally:

• 9 tests passing;
• TypeScript check and build passing;
• package dry run passing;
• zero npm audit vulnerabilities;
• strict pre-publish secret scan passing;
• compiled CLI verified against clean and dirty fixtures.

No live SharePoint tenant validation has been performed yet.

Repository: github.com/vystartasv/spfx-assurance

The useful test is not whether this catches an intentionally broken fixture. It is whether the rules stay trustworthy on real SPFx repositories without becoming a noisy false-positive machine.