- Can I install hearsay/require-js-bundle in a Laravel application with Composer?
- No, not as a working Laravel integration. It is a Symfony2 bundle with no Laravel service provider, package discovery, or config publish tag, and its Symfony 2 era dependencies will likely conflict with a modern Laravel runtime. You can read the code as reference, but composer require is not a viable integration path.
- Does this package support Laravel 10 or Laravel 11?
- No. It targets Symfony2 and Twig, not Laravel, and there is no evidence of Laravel version support. The repository is Symfony2 era code, so do not expect compatibility work for Laravel 10, 11, or newer. For Laravel, use Vite and native ES modules instead.
- How do I configure RequireJS module paths and shims in Laravel if I use this bundle's schema?
- Lift the declarative schema into config/requirejs.php. The bundle's useful data includes baseUrl, paths, shim, deps, map, and waitSeconds, and those port cleanly even though the Symfony DI extension does not. Then render that config into a script tag or data attribute from a Blade directive or view component.
- What are the Twig helpers in HearsayRequireJsBundle and what is the Laravel equivalent?
- The bundle provides Twig helpers to load RequireJS scripts and render configuration. In Laravel there is no Twig integration; reproduce the output with a Blade directive, a Blade component, or a small helper that emits the same script tags. Do not try to wire the Symfony Twig extension into Laravel.
- Does the bundle include an r.js optimizer wrapper and can I use it in Laravel?
- Yes, the bundle wraps the RequireJS optimizer and shells out to r.js, but that wrapper is coupled to Symfony configuration and services. In Laravel you would call r.js directly from a build script or keep it as a transitional step alongside Vite. Do not depend on the bundle's optimizer service.
- What is the best Laravel alternative to RequireJS and this bundle?
- Laravel's supported path is Vite with laravel-vite-plugin and native ES modules. Use Vite for bundling and module loading, and keep r.js only as a transitional build step if you must support an existing AMD graph. RequireJS and AMD are a superseded module format, so new Laravel work should not adopt it.
- Is hearsay/require-js-bundle maintained and safe for production?
- The assessment flags it as archived with high organizational and technical risk, including no security responsiveness and no PHP version compatibility work. It has zero dependents, so there is little field evidence for edge-case behavior. For production Laravel, treat it as reference material, not a dependency.
- How would I migrate a Symfony2 RequireJS app to Laravel?
- Separate the legacy app from the Laravel target. Keep the Symfony2 app pinned and unchanged in maintenance mode, record the bundle in your dependency inventory with an EOL flag, and build the Laravel target with Vite and ES modules. If you need parity, copy the RequireJS config schema and reproduce the Twig helper output with Blade.
- Can I test the RequireJS optimizer behavior before committing to a migration?
- Yes, but test r.js directly rather than through the bundle. Capture the legacy config's shim handling, path mapping, and build ordering, then run r.js against representative builds to see what is hard to reproduce. That scoping exercise determines whether the reference read is a short task or a multi-week spike.
- Who should own this package if we fork or maintain it?
- Archived packages need a named owner and a documented exit plan before the first commit. Decide whether the estate has one RequireJS app or several; one app is a migration ticket, several is a program with a shared ES-module target. If you cannot name an owner, do not fork it.