Weave Code
View Engine Laravel Package
hyperf/view-engine
View engine abstraction for Hyperf, bringing Laravel-style view rendering and Blade templates to coroutine-based PHP apps. Configure multiple template engines—Blade, Smarty, Twig, Plates—and render views with a familiar manager API, caching, and namespace support.
[READ ONLY] Laravel View Engine for Hyperf
Frequently asked questions about View Engine
- Can I use hyperf/view-engine in a Laravel application?
- No. It is the view component for the Hyperf framework and assumes Hyperf's PSR-11 container conventions, its config provider and annotation bootstrap, and a Swoole or Swow event loop rather than Laravel's per-request FPM lifecycle. Its ViewEngine contract is a different interface from Laravel's view factory and Blade compiler, so bridging the two costs more than it saves. For a Laravel app, use the native Blade and view() stack and evaluate this package only for Hyperf services.
- How do I install hyperf/view-engine?
- Run composer require hyperf/view-engine and make sure the Swoole or Swow extension, hyperf/framework, and a PSR-11 container binding for the engine adapters are in place. You also need a writable compiled-template cache directory and engine-specific options such as template paths. Then register the config provider and publish the view configuration through Hyperf's standard bootstrap.
- Which Laravel versions does hyperf/view-engine support?
- None directly; it is not a Laravel package, so Laravel 10 or 11 compatibility does not apply. Its release line tracks Hyperf (the 3.2.x series) and expects a compatible PHP floor plus a Swoole or Swow runtime, so verify those against your runtime image before installing. If you need Blade in Laravel, use the framework's built-in Blade compiler instead.
- Which template engines does hyperf/view-engine support?
- It ships adapters for Blade (through hyperf/view), Twig, Smarty, Plates, and ThinkTemplate behind a single ViewEngine interface and factory. Each adapter keeps its own syntax, options, and compiled-template handling, so you can mix engines in one application. You can also register your own engine through the extensible adapter architecture.
- How do I configure multiple view engines and template paths in Hyperf?
- Define each engine and its options in the view configuration, including template paths, cache location, and engine-specific settings, then resolve the right engine by name through the factory or dependency injection. Hyperf's config provider loads these settings at bootstrap, and namespace support lets you map template directories to logical namespaces. Because configuration is container-driven, you can bind different engines for different services or coroutines.
- How do I add a custom view engine adapter to hyperf/view-engine?
- Implement the ViewEngine interface, wrapping your engine's render and compile behavior, and register it so the factory can resolve it by name. Bind the adapter in Hyperf's container and add its options to the view configuration. Keep the adapter stateless where possible, since it will be reused across requests inside a long-running worker.
- Is hyperf/view-engine safe in long-running Swoole workers?
- It can be, but state is the risk: engine instances, compiled templates, and static caches persist across requests, so a stateful adapter can leak data between coroutines or grow memory without bound. Keep adapters stateless, avoid request-scoped data in singletons, and treat compiled templates as ephemeral, version-keyed build output. Clear the cache on deploy and monitor worker memory.
- Can concurrent Hyperf workers race when compiling the same template?
- Yes. Multiple workers can compile the same template at once, and if the compiled-template cache lives on shared storage, simultaneous writes can produce partial or corrupted artifacts. Make the write path atomic by writing to a temporary file and renaming it, warm the cache during build or deploy, and keep cache directories version-keyed so a rollback cannot serve stale compiled files.
- How do I test views rendered through hyperf/view-engine?
- Render each configured engine adapter in an integration test and assert on the output, since the abstraction hides engine-specific behavior that unit tests can miss. Cover namespace resolution, cache hits and misses, and error paths for a missing template. Run these tests in CI with the same Swoole or Swow runtime and PHP version as production, and verify the compiled cache directory is writable in the test environment.
- Is hyperf/view-engine actively maintained, and what changed in v3.2.2?
- Version 3.2.2 is a patch-level bump from 3.2.0, so semver implies no public API breakage, but the upstream release notes contain only a comparison link and no changelog entries. Review the commit diff or merged pull requests before approving the bump, then update the constraint, run composer update hyperf/view-engine, clear the compiled-template cache, and smoke-test every engine adapter. Confirm the PHP and Swoole version floors, and track whether the package is a direct or transitive dependency so someone owns the patch cadence.
Weaver
How can I help you explore Laravel packages today?