- What does symfony/polyfill-apcu actually do?
- It provides apcu_* functions and the APCuIterator class for projects that still rely on the legacy APC extension. It is a name shim that delegates to apc_* functions, not a real APCu implementation. It activates through Composer files autoload and only defines functions that are not already defined. It is not a caching backend.
- Can I use symfony/polyfill-apcu to make Laravel's apcu cache driver work?
- Generally no. Laravel's CacheManager guards the apcu driver with extension_loaded('apcu') and throws if ext-apcu is absent, and this polyfill does not make that extension load. The polyfill can define functions, but it cannot satisfy extension or capability checks. Use a supported cache driver or install ext-apcu instead.
- How do I install symfony/polyfill-apcu in a Laravel project?
- Install it with composer require symfony/polyfill-apcu. It has no transitive dependencies and uses Composer files autoload. No service provider, config file, or AppServiceProvider registration is needed or provided. It is MIT licensed.
- Does symfony/polyfill-apcu support Laravel 10, 11, or 12?
- It is a framework-agnostic PHP polyfill, so the Laravel version is mostly irrelevant. What matters is whether your PHP runtime has legacy ext-apc and lacks ext-apcu, or whether code calls apcu_* directly. The package docs do not include a Laravel-specific supported-version matrix. Laravel's own APCu cache store still requires ext-apcu.
- What happens if neither APC nor APCu is installed?
- The polyfill defines apcu_* functions, but those definitions delegate to apc_* functions. If legacy APC is also absent, calls resolve to undefined apc_* functions and produce a fatal Error, not a graceful fallback. So it is not a safety net for hosts with no APC extension. Verify extension_loaded('apc') before relying on it.
- Why doesn't extension_loaded('apcu') return true after installing this package?
- Because it is a function polyfill, not a PHP extension. Composer autoload defines functions in userland, but no extension is registered with PHP. Code that gates behavior on extension_loaded('apcu') or apcu_enabled() still sees false. That includes Laravel's cache driver guard and third-party packages using the same checks.
- Is symfony/polyfill-apcu a replacement for the APCu extension?
- No. It only backports function names and the APCuIterator class by delegating to legacy apc_*. It does not provide shared memory, APCu performance, or extension-level capability detection. Treat it as a compatibility shim for legacy APC stacks, not as an APCu substitute. For real APCu behavior, install ext-apcu.
- What are the performance and CLI concerns with this polyfill?
- Calls delegate to legacy APC, so latency and semantics depend on that extension and can differ from native APCu. Shared memory behavior is per SAPI and per pool, and CLI processes such as queue workers and artisan commands may see different or empty caches. That can create confusing cache divergence between web and CLI. Benchmark and test it in your actual deployment before relying on it.
- Is symfony/polyfill-apcu actively maintained?
- It is part of Symfony's polyfill collection and follows Symfony's split-release process. Recent releases and no-significant-changes changelogs reflect that process, not necessarily active feature development. The package has a very narrow scope. Check the repository and the main Polyfill README for the current maintenance and support posture.
- What alternatives should I consider instead of symfony/polyfill-apcu?
- If you need APCu caching, install ext-apcu and use Laravel's APCu cache driver where supported. If the goal is portable caching, use Laravel's Cache contract with file, database, Redis, or another supported driver. If code calls apcu_* directly, refactor that call site or provide your own adapter rather than shimming functions.