DEV Community: Vilius

m365-extension-control: evidence and readiness checks for SPFx estates

Vilius — Mon, 31 Aug 2026 17:19:57 +0000

SPFx teams do not only need to know whether a project builds. They need to know whether the project on disk still matches the release intent recorded by the team.

That is the problem behind m365-extension-control.

It is a small, offline, deterministic CLI for SPFx and Microsoft 365 extension estates. An estate.json file records the declared owner, lifecycle status, release channel, expected solution version, expected SPFx version, and project path. The CLI compares that declaration with bounded facts read from the project directory.

Commands:

m365-extension-control scan <project-dir>
m365-extension-control inventory --manifest estate.json
m365-extension-control evidence --manifest estate.json
m365-extension-control preflight --manifest estate.json --id <solution-id>

The MVP reports:

solution and component identity;
solution-version drift;
SPFx-version drift;
lifecycle/channel inconsistencies;
ownership gaps;
malformed or missing project metadata;
explicit verified, warning, blocked, and not-tested statuses;
deterministic JSON and Markdown evidence;
local preflight decisions with exit codes suitable for CI.

The repository includes a four-solution acceptance estate covering verified, warning, blocked, and not-tested states. The implementation has 20 deterministic tests, TypeScript checks, a compiled CLI, package dry-run validation, and GitHub Actions CI.

The important boundary is deliberate: this tool does not validate a SharePoint tenant, approve an App Catalog submission, verify permissions, deploy anything, or claim production readiness. It reports local file evidence only.

This is the next layer in my SPFx tooling work:

spfx-factory creates governed projects;
spfx-assurance checks one project internally;
spfx-estate-doctor inventories projects on disk;
m365-extension-control compares declared intent with on-disk facts and produces a local release gate.

Repository: https://github.com/vystartasv/m365-extension-control

Feedback and real-world estate examples are welcome, especially cases where a release or upgrade failed because the declared state and deployed state diverged.

Tags: #opensource #typescript #sharepoint #devtools

Turning spfx-factory Into an Evidence-Gated SPFx Agent

Vilius — Mon, 31 Aug 2026 16:15:46 +0000

Turning spfx-factory Into an Evidence-Gated SPFx Agent

AI can generate an SPFx project. That is not the same as proving the project is ready.

The latest spfx-factory release adds an evidence ledger around the existing generation workflow:

SCAFFOLD — whether the official scaffold completed;
CODEX — whether implementation was requested and completed;
POLICY — whether static policy checks passed;
LOCAL — whether requested local npm checks passed;
ASSURANCE — whether an independent spfx-assurance check ran;
TENANT — always explicitly not-tested.

Every check reports one of:

verified;
warning;
blocked;
not-tested.

The existing factory report status remains backward compatible. Evidence is recorded in a parallel evidence field rather than silently changing the old contract.

Independent assurance without hidden installation

The factory can invoke spfx-assurance when it is already available through SPFX_ASSURANCE_BIN or PATH.

It does not:

call npx;
download a dependency;
import the ESM checker into the CommonJS factory;
access a tenant;
claim permissions or App Catalog approval;
fabricate a successful check when the tool is unavailable.

When the checker is absent, the result is not-tested with an actionable explanation.

Inspect evidence

spfx-factory inspect --output ./generated
spfx-factory inspect --output ./generated --json

The inspection command is read-only. It reads the existing factory-report.json, prints the evidence, and does not rerun generation or verification.

Warnings do not break an otherwise green run by default. Teams that want warning-gating can opt in:

spfx-factory generate \
  --spec specs/document-review.json \
  --output ./generated \
  --fail-on warning

Verification boundary

This is local evidence, not tenant validation. A green local report does not prove:

SharePoint permissions;
App Catalog approval;
tenant deployment;
production data access;
runtime behaviour in a specific tenant.

That limitation is part of the report, not a footnote hidden outside it.

Why this matters

The useful product boundary for AI-assisted SPFx development is not “the model wrote code.” It is:

The system cannot call the work complete without showing what was checked, what passed, and what remains unknown.

The project is open source:

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

The release adds an evidence layer to the factory while preserving its existing generation and policy behaviour.

spfx-estate-doctor: Inventory an SPFx Estate Without Touching a Tenant

Vilius — Mon, 31 Aug 2026 16:01:41 +0000

spfx-estate-doctor: Inventory an SPFx Estate Without Touching a Tenant

A single SPFx project can be inspected deeply. An organisation's collection of projects is a different problem.

Which solutions are present? Which use old SPFx versions? Which have no owner information? Which projects reuse a component or solution ID? Which directories are not packaged solutions at all?

I built spfx-estate-doctor as an offline, read-only scanner for that shallow-but-wide view.

Usage

npx spfx-estate-doctor scan ./webparts/alpha ./webparts/bravo \
  --json estate.json --md estate.md

For larger explicit sets, provide a newline-delimited manifest:

# projects.txt
../webparts/alpha
../webparts/bravo
../webparts/legacy

npx spfx-estate-doctor scan --manifest projects.txt

There is deliberately no recursive discovery. The tool scans only directories explicitly supplied by the operator.

What it checks

Per project:

package identity;
SPFx dependency and version;
SPFx-to-Node compatibility snapshot;
solution manifest shape;
component manifest shape;
owner information.

Across the estate:

duplicate component IDs across projects;
duplicate solution IDs across projects.

Missing files are reported as skipped, not quietly marked healthy. That distinction matters: no package-solution.json means “not checked,” not “verified.”

Why it is intentionally boring

The scanner makes no network calls, executes no project commands, reads no credentials, invokes no Microsoft 365 CLI, and writes no files inside inspected projects. Its JSON output contains no timestamps or absolute machine paths, so the same estate produces a byte-identical report that can be diffed over time.

The report says exactly what it knows:

Offline inventory of local project files only. This is not tenant validation, App Catalog state, deployment status, or a security audit.

It cannot tell you what is deployed, whether a tenant permission is granted, whether a project builds, or whether the code is secure. Those are separate checks.

Relationship to spfx-assurance

spfx-assurance is the one-project deep verifier. spfx-estate-doctor is the many-projects shallow inventory layer.

spfx-estate-doctor  →  What exists across the estate?
spfx-assurance      →  Does this project look shippable locally?

Both produce explicit evidence rather than a vague health score.

Verified locally:

15 deterministic tests passing;
TypeScript check and build passing;
package dry run containing 9 intended runtime files;
zero npm audit vulnerabilities;
strict pre-publish scrub passing;
compiled CLI detecting cross-project duplicate IDs;
deterministic report and read-only behavior verified.

No live SharePoint tenant validation has been performed.

Repository: github.com/vystartasv/spfx-estate-doctor

The public question is simple: does this remain useful when pointed at real project directories, without turning into an invasive dashboard or a machine that invents certainty?

spfx-assurance: Offline Release Checks for SharePoint Framework Projects

Vilius — Mon, 31 Aug 2026 15:46:10 +0000

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.

A Typed Repository Layer for SharePoint CRUD in SPFx

Vilius — Mon, 31 Aug 2026 12:19:23 +0000

A Typed Repository Layer for SharePoint CRUD in SPFx

PnPjs is a good low-level client for SharePoint. The problem is what application code starts to look like when every feature repeats list names, internal field names, lookup expansion, ETag handling, response mapping, and error translation.

I built spfx-data-kit as a small repository layer above @pnp/sp v4.

The contract

A feature works with a domain-oriented resource:

const result = await requests.update(
  id,
  { title: "Updated", status: "approved" },
  { etag },
);

The feature does not need to know that title maps to SharePoint's Title field, or that an update may return no response body.

The public contract currently supports:

list
get
create
update
remove

Single-item results carry the current ETag:

{
  data: request,
  etag: '"7"'
}

Lists keep entities ergonomic and expose ETags separately:

{
  data: requests,
  etags: {
    "42": '"7"'
  }
}

What it adds above PnPjs

spfx-data-kit is not a replacement for PnPjs and does not attempt to cover all SharePoint APIs. It adds application-level conventions:

explicit domain-to-SharePoint field mapping;
typed create and update inputs;
stable error kinds for validation, not-found, conflict, permission, transient, and unknown failures;
first-class optimistic-concurrency inputs through ETags;
update re-reads after SharePoint's possible 204 No Content response;
bounded async paging with pageSize, maxPages, and an overall top cap;
a local in-memory adapter implementing the same CRUD contract;
cloning at local adapter boundaries to prevent accidental shared-state mutation.

This keeps TanStack Query in its proper place: TanStack can manage cache, refetch, invalidation, and optimistic UI while the repository owns SharePoint semantics.

React feature
    ↓
TanStack Query
    ↓
spfx-data-kit
    ↓
PnPjs v4
    ↓
SharePoint

Why a local adapter?

A mocked PnPjs fluent chain tests whether a particular call sequence happened. It does not provide much confidence that the feature's CRUD behavior is coherent.

The local adapter lets contract tests exercise validation, ETag conflicts, cloning, IDs, and CRUD behavior without a tenant. Tenant validation remains a separate responsibility: permissions, required fields, content types, and tenant configuration cannot be proven locally.

Current status

This is an early MVP, released as source on GitHub rather than presented as a finished enterprise framework.

Verified locally:

9 deterministic tests passing;
TypeScript build passing;
no-emission type check passing;
package dry-run passing;
npm dependency audit reporting zero vulnerabilities;
pre-publish secret scrub passing.

Not yet validated against a live SharePoint tenant. That is the next honest test: initialize it after super.onInit(), connect it to a real list, and verify permissions, field requirements, live CRUD, and stale-ETag conflicts.

The repository is open for review:

github.com/vystartasv/spfx-data-kit

Feedback on the contract matters more than adding another layer of abstractions. If this is only a shorter spelling of PnPjs, it is not useful enough. The goal is a small, explicit boundary that makes SharePoint application code easier to test and harder to get subtly wrong.

Building a Verified SPFx Factory Instead of Another Code Generator

Vilius — Mon, 31 Aug 2026 11:08:41 +0000

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:

official scaffold
Codex implementation
policy scan
dependency installation
explicit test script
build
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.

Help wanted: validate a React governance and site lifecycle dashboard SPFx sample

Vilius — Sun, 30 Aug 2026 20:31:56 +0000

A new read-only React sample is ready for the PnP SharePoint Framework webparts repository:

Pull request: https://github.com/pnp/sp-dev-fx-webparts/pull/6488
Sample: samples/react-governance-site-lifecycle-dashboard/

The web part reads bounded SharePoint REST site-inventory sources with GET only. It surfaces site title and URL, template, owners, hub association, sharing mode, storage or usage, last activity, review and expiration dates, and deterministic inactive or needs-review signals.

The sample validates same-tenant HTTPS REST URLs, preserves managed paths, validates OData next links, defensively parses malformed rows, and limits reads to four sources, 50 rows per page, five pages, and 200 items per source. It keeps empty, partial, permission, throttling, retry, and generic error states visible.

Lifecycle classification uses an explicit reference date, so tests and reviews are deterministic. The UI is responsive, keyboard-usable, semantic, and does not rely on color alone for status.

This is a governance review aid—not an administration tool. It cannot create, update, delete, permission, hub, site, lifecycle, or content data. It requests no Graph permissions and stores no credentials or secrets.

Local verification completed:

7 deterministic tests passed.
Read-only verifier passed.
SPFx lint, TypeScript, Sass, and webpack validation passed.
Production bundle and .sppkg packaging passed.
Gallery metadata, configuration, scope, whitespace, and secret-marker checks passed.
Generated outputs were removed before commit.

Could someone with a SharePoint Online tenant please validate representative site-inventory endpoints and real data, including managed paths, missing fields, inactive sites, due or upcoming review dates, hub associations, sharing/storage fields, paging bounds, empty and malformed data, partial failures, limited permissions, throttling, keyboard access, and responsive layout? Real tenant screenshots would be especially helpful; none are fabricated locally.

Thank you for helping validate and improve this community sample.

Help wanted: validate a React room and resource capacity planner SPFx sample

Vilius — Sun, 30 Aug 2026 19:31:57 +0000

A new read-only React sample is ready for the PnP SharePoint Framework webparts repository:

Pull request: https://github.com/pnp/sp-dev-fx-webparts/pull/6487
Sample: samples/react-resource-capacity-planner/

The web part reads bounded SharePoint REST resource and reservation lists with GET only. It calculates daily and weekly utilization, capacity, deterministic overlap conflicts, available working-hour slots, resource units, and source-level partial/error states.

It validates HTTPS same-tenant REST URLs, field names, resource IDs, ISO date ranges, time zones, horizons, page sizes, and item limits. The UI includes empty, malformed, partial, permission, throttling, retry, loading, keyboard, responsive, and non-color-only states.

This is a planning view—not a booking system. It does not create, update, or cancel reservations and requests no additional API permissions. Microsoft Graph Bookings/Exchange integration is intentionally documented as a separate consent boundary rather than assumed.

Local verification completed:

8 deterministic tests passed.
GET-only verifier passed.
SPFx lint, TypeScript, Sass, and webpack validation passed.
Production bundle and .sppkg packaging passed.
Gallery metadata, configuration, scope, and secret checks passed.
Generated outputs were removed before commit.

Could someone with a SharePoint Online tenant please validate representative rooms/resources and reservations, including overlapping and touching intervals, multi-unit capacity, limited permissions, throttling, partial failures, managed paths, date horizons, time-zone display, keyboard navigation, and responsive layout? Real tenant screenshots would be especially helpful; none are fabricated locally.

Thank you for helping validate and improve this community sample.

Help wanted: validate a React retention and records review SPFx sample

Vilius — Sun, 30 Aug 2026 18:05:29 +0000

Help wanted: validate a React retention and records review SPFx sample

A new read-only React sample is ready for the PnP SharePoint Framework webparts repository:

Pull request: https://github.com/pnp/sp-dev-fx-webparts/pull/6485
Sample: samples/react-retention-records-review/

The web part reads bounded SharePoint document-library and folder inventories through PnPjs and presents available record/retention indicators, modified dates, content types, and missing review metadata. It classifies permission, throttling, network, and configuration failures and shows partial results where possible.

This is an inventory and review aid—not retention-policy enforcement. It does not apply retention labels, declare records, mutate metadata, or request additional permissions. It uses PnPjs v4 async iteration with a maximum page cap and explicitly avoids fetching beyond that cap.

Local verification completed:

6 deterministic tests passed, including mocked PnPjs v4 async pagination and no-overfetch behavior.
SPFx lint, TypeScript 5.3.3, Sass, and webpack validation passed.
Production bundle and .sppkg packaging passed.
Diff, metadata, config, and secret scans passed.
Generated outputs were removed before commit.

Could someone with a SharePoint Online tenant please test representative document libraries and folders, including limited permissions, throttling, partial failures, managed paths, review fields, record/retention indicators, pagination limits, keyboard access, and responsive layout? Real tenant screenshots would be especially helpful; none are fabricated locally.

Thank you for helping validate and improve this community sample.

Help wanted: validate a React multilingual intranet switcher SPFx sample

Vilius — Sun, 30 Aug 2026 17:30:42 +0000

Help wanted: validate a React multilingual intranet switcher SPFx sample

A new read-only React sample is ready for the PnP SharePoint Framework webparts repository:

Pull request: https://github.com/pnp/sp-dev-fx-webparts/pull/6484
Sample: samples/react-multilingual-intranet-switcher/

The web part presents locale-specific intranet navigation and content links from bounded local JSON configuration. It chooses an initial locale using exact browser-locale matching, language fallback, and then the configured default. Users always have an explicit accessible language selector.

The sample deliberately does not translate content, infer translations, call translation APIs, read SharePoint data, or mutate tenant state. It accepts only same-origin HTTP(S) links and rejects malformed, credential-bearing, unsafe, and external URLs.

Local verification completed:

6 deterministic Mocha tests passed.
SPFx lint, TypeScript, Sass, and webpack validation passed.
Production bundle and .sppkg packaging passed.
Diff, metadata, config, and secret scans passed.
Generated outputs were removed before commit.

Could someone with a SharePoint Online tenant please test this with two or more configured locales, including managed-path URLs, unsupported browser locales, malformed configuration, unsafe links, keyboard navigation, responsive layout, and users without additional API permissions? Real tenant screenshots would be especially useful; none are fabricated locally.

Thank you for helping validate and improve this community sample.

Help wanted: validate a React accessibility content auditor SPFx sample

Vilius — Sun, 30 Aug 2026 17:17:46 +0000

Help wanted: validate a React accessibility content auditor SPFx sample

A new read-only React sample is ready for the PnP SharePoint Framework webparts repository:

Pull request: https://github.com/pnp/sp-dev-fx-webparts/pull/6483
Sample: samples/react-accessibility-content-auditor/

The web part audits bounded, allow-listed SharePoint page or list content and highlights missing image alt text, empty or generic link text, skipped heading levels, malformed content, and empty required fields. Each finding includes severity, rule, evidence, item, and a safe remediation link.

It is explicitly a heuristic review aid—not a WCAG conformance certification tool—and it performs no create, update, or delete operations.

Local verification completed:

15 deterministic Jest tests passed.
SPFx DEBUG and SHIP builds passed.
Production .sppkg packaging passed.
Generated build outputs were removed before commit.
Scope and secret checks passed.

Could someone with a SharePoint Online tenant please test this against representative modern pages or list content and report back on the PR? Useful checks include alt-text and link-text findings, heading-order detection, malformed content, managed-path remediation URLs, permissions, throttling, keyboard access, and responsive layout. Real tenant screenshots would be especially helpful; none are fabricated here.

Thank you for helping validate and improve this community sample.

Help wanted: validate a React document metadata review SPFx sample

Vilius — Sun, 30 Aug 2026 16:51:17 +0000

Help wanted: validate a React document metadata review SPFx sample

A new read-only React sample is ready for the PnP SharePoint Framework webparts repository:

Pull request: https://github.com/pnp/sp-dev-fx-webparts/pull/6482
Sample: samples/react-document-metadata-review/

The web part reviews a bounded SharePoint document-library or folder view and highlights missing or invalid metadata. It supports required text, choice, and taxonomy field checks, then provides safe links for people to remediate the source documents.

It deliberately performs no create, update, or delete operations. The README documents the SharePoint permissions, configuration format, and tenant validation steps.

Local verification completed:

13 deterministic Jest tests passed.
SPFx DEBUG and SHIP builds passed.
Production .sppkg packaging passed.
Scope and security review found no secrets or unrelated changes.

Could someone with a SharePoint Online tenant please test this against a representative document library and report back on the PR? Useful checks include metadata highlighting, folder scoping, taxonomy values, permission-denied and throttling behavior, safe links, keyboard access, and responsive layout. Real tenant screenshots would be especially helpful; none are fabricated here.

Thank you for helping validate and improve this community sample.