0.9.0

AssegaiPHP Core 0.9.0

0.9.0 is the platform-alignment and hardening release for assegaiphp/core.

This release brings Core onto the AssegaiPHP 0.9 line, raises the platform baseline to PHP 8.4, updates the first-party package graph to the new release line, and hardens several framework-critical areas including routing, static asset serving, exception handling, request/runtime scoping, and OpenAPI generation.

Highlights

PHP 8.4 baseline and ecosystem alignment

assegaiphp/core now requires PHP >=8.4.

Core is aligned to the 0.9.x AssegaiPHP package line and now targets:

• assegaiphp/common: ^0.9.0
• assegaiphp/forms: ^0.9.0
• assegaiphp/util: ^0.9.0
• assegaiphp/validation: ^0.9.0
• assegaiphp/attributes: ^1.0
• symfony/console: ^8.0

This is the main dependency baseline for the broader 0.9 framework release.

Static asset serving is safer

The front-controller/runtime resource path handling has been hardened so public assets are streamed directly and are no longer routed through PHP execution semantics.

This closes a dangerous class of issues where static assets containing PHP-like byte sequences could be misinterpreted or mishandled.

Additional path hardening includes protection against:

• directory traversal
• hidden path segments by default
• unsafe script-like assets being exposed as public files

Support was also preserved for standards-based public assets such as:

• /.well-known/acme-challenge/...
• /.well-known/apple-app-site-association

That means certificate verification and domain association flows continue to work while the general hidden-segment guard remains in place.

Router and host matching improvements

Routing behavior has been tightened in several important ways.

Highlights include:

• exact routes winning over wildcard routes
• exact controllers winning over wildcard controllers
• better fallback to the last matched ancestor controller for nested modules
• better fallback handling for unknown root paths
• host-aware routing where exact host controllers beat dynamic and generic controllers
• dynamic host token capture for subdomain-style routes
• support for controllers matching against multiple hosts
• route metadata precedence fixes for status codes, headers, and redirects

This makes route resolution more predictable and reduces surprising edge cases in larger module graphs.

Request scope and dependency injection hardening

Core now does a better job of resolving controllers, guards, interceptors, and providers through request scope.

That includes:

• request-scoped guard and interceptor resolution
• controller injection from same-module providers
• controller injection from exported imported-module providers
• correct rejection when imported modules do not export the provider being requested

These changes make module boundaries and provider visibility behave more consistently.

Runtime and OpenSwoole improvements

The runtime layer has seen substantial hardening.

This includes:

• clearer runtime selection and validation
• named runtime resolution
• project/runtime config-based factory creation
• environment-based runtime overrides
• stronger OpenSwoole configuration validation
• request-scope hydration from runtime context
• response metadata bridging for OpenSwoole emitters
• worker lifecycle isolation across sequential requests
• recovery from failed requests in worker mode
• hook flag normalization for OpenSwoole settings

Core also now routes escaped OpenSwoole handler failures back through the framework’s exception handling path more reliably.

Exception handling and error rendering

Exception handling behavior has been tightened across both browser and API-style flows.

Highlights include:

• Whoops choosing HTML for browser-style GET requests
• JSON responses for non-GET or runtime HTTP contexts
• better error page shell rendering
• production-safe handling of HTTP exceptions without leaking internal detail
• response-scope emitter integration in exception paths

This gives Core a more predictable separation between developer-facing debug output and production-safe responses.

OpenAPI and API docs generation

The API docs path has been strengthened and tested more thoroughly.

This includes:

• DTO schema inclusion in generated OpenAPI output
• validation metadata appearing in generated specs
• raw JSON response support for OpenAPI emission without the API envelope
• Swagger UI rendering against the generated spec
• compatibility with downstream Postman and TypeScript export flows
• correct binding to the explicit workspace when generating from a project context

Web Components and view integration

The Web Components helpers continue to mature in 0.9.0.

Notable improvements include:

• safe JSON escaping for component props in HTML attributes
• runtime bundle resolution through configuration
• the ability to disable bundle helpers when needed
• hot reload tag injection when watch mode is active

The helper naming and guide direction have also been aligned around the shorter wcProps terminology.

Security-focused template and config defaults

New-project defaults and template behavior across the wider framework line were updated to better separate concerns and improve security posture.

Important defaults now include:

• sensitive database/auth config living in config/secure.php
• secure.php overriding lower-priority config files
• auth-sensitive values using environment-driven defaults such as env('APP_SECRET_KEY', 'your-secret-key')
• empty auth strategy lists until strategies are intentionally registered
• cleaner default template separation between service-side data preparation and view rendering

What changed behaviorally

A few changes are important to call out for upgraders:

• PHP 8.4 is now required.
• Static assets are now streamed more defensively and no longer risk PHP interpretation issues.
• Hidden path segment filtering is stricter, while /.well-known/... remains allowed.
• Routing precedence is more explicit and consistent in wildcard and host-matching scenarios.
• Provider resolution across module boundaries is stricter about exports.
• Runtime validation is tighter, especially for OpenSwoole settings.
• The wider package graph now expects the 0.9.x line of first-party packages.

Upgrade notes

If you are upgrading from 0.8.x:

• PHP 8.4 or newer is now required.
• Upgrade the first-party AssegaiPHP packages together on the 0.9.x line.
• Refresh your lock file after updating constraints so Composer reflects the new dependency graph.
• If you serve public assets through the framework runtime, review any assumptions about hidden files and ensure standards-based /.well-known/... assets still live under public/.
• If you rely on module imports for DI, verify that required providers are explicitly exported.
• If you use OpenSwoole, review runtime config against the stricter validation path.

Verification

Verified with:

composer validate --strict

composer analyze

composer test

What comes next

0.9.0 gives Core a stronger security and runtime foundation. The next stretch toward 1.0 should continue focusing on:

• tighter framework-package harmony across the whole ecosystem
• more integration coverage around real application scaffolds
• continued runtime hardening
• deeper documentation alignment with the now-stable 0.9 platform behavior

Full Changelog: 0.8.4...0.9.0