Modernize the frontend with TypeScript and streamline release packaging

[ingeniumed]

Description

Modernizes the plugin frontend and build tooling while preserving existing governance rule behaviour.

What changed

• Migrated frontend source, unit tests, Playwright tests, and configuration from JavaScript/JSX to TypeScript/TSX.
• Enabled strict TypeScript checking in local development and CI.
• Split the editor integration into smaller typed modules with clearer responsibilities.
• Simplified nested governance traversal and removed mutation and array-reversal handling.
• Modernized block locking with the native useBlockEditingMode API available in supported WordPress versions.
• Bundled the settings-page script through @wordpress/scripts and switched REST requests to @wordpress/api-fetch.
• Improved settings-page structure, accessibility, loading state, and error handling.
• Removed unused direct dependencies, including @wordpress/compose, babel-jest, and webpack.
• Updated production builds to use wp-scripts build, producing optimized bundles without source maps.
• Added CI verification that committed production bundles are current.
• Updated release packaging to use wp-scripts plugin-zip with an explicit vip-governance/ root folder.
• Updated the README for TypeScript development and the WordPress 6.8/6.9 block-inserter limitation.

Behaviour and compatibility

Governance rule decisions are intended to remain unchanged:

• Existing block matching behaviour is retained.
• Existing wildcard matching behaviour is retained.
• Nested rule precedence is retained.
• allowedBlocks beneath wildcard parent settings remains unsupported.
• Block insertion, editing, settings, and feature permissions continue to use the same effective rules.

One observable behaviour has been corrected: parent arrays passed to the public insertion and editing filters are now consistently nearest-parent-first, matching the documented contract. Trunk could expose root-first order when nested settings were present because the shared array was mutated during lookup. Consumers relying on that accidental ordering may observe this correction.

The settings page has deliberate visual and accessibility improvements. Release ZIPs are also smaller because development-only files, TypeScript source, tests, and lockfiles are no longer included.

Follow-up opportunity

A separate issue should consider replacing the legacy block-name matching behavior with exact rule matching and adding intentional wildcard-parent support for nested allowedBlocks. That change would explicitly drop compatibility with the current legacy matching behaviour and should be handled separately.

Steps to Test

1. Run npm ci.

2. Run composer install.

3. Run npm run lint.

4. Run npm test.

5. Start the isolated WordPress environment:

   npx wp-env start --config=.wp-env.test.json
   

6. Run:

   npm run test:e2e

7. Open the VIP Block Governance settings page and verify:

   • Governance rules validate successfully.
   • Role and post-type selectors display correctly.
   • Selecting a role and post type loads the combined rules.

8. Open the post editor and verify:

   • Only allowed blocks are available.
   • Nested block restrictions apply.
   • Governed block settings use the expected palettes and controls.
   • Disallowed blocks cannot be edited.
   • Code editor and block-locking availability follow allowedFeatures.

9. Run npm run release:zip, unzip vip-governance.zip, and verify:

   • The root folder is vip-governance/.
   • Production bundles and asset manifests are included.
   • Development source and tests are excluded.

Screenshots

[alecgeatches]

Looking good! Tested locally with no issues.