- Is evheniy/jquery-bundle a Laravel package?
- No. evheniy/jquery-bundle is a Symfony2 bundle, not a Laravel package. Its entire surface area is a Symfony bundle class registered in AppKernel plus a Twig helper that renders a jQuery script tag. There is no Laravel service provider, facade, container binding, or publishable config, so it does not target Laravel at all.
- Can I install evheniy/jquery-bundle in a Laravel application with Composer?
- You should not, and it will not work the way a Laravel package does. The package expects Symfony bundle conventions: registration in AppKernel and a jquery key in config.yml handled by the Symfony config component. Laravel's package discovery, service providers, and config publishing have nothing to hook into here. Composer resolution will also likely fail on modern PHP 8.x stacks because of the old platform constraints.
- What does the evheniy/jquery-bundle package actually do?
- It outputs a single script tag pointing at ajax.googleapis.com for a configurable jQuery version, or at a local file path if you prefer. Configuration also controls the CDN domain, whether HTML5 or legacy script markup is emitted, and whether the script loads asynchronously. Functionally the entire value is one line of HTML in your template.
- How do you install and register JqueryBundle in a Symfony2 project?
- Run composer require evheniy/jquery-bundle "1.*" or add the same constraint to composer.json. Then register new Evheniy\JqueryBundle\JqueryBundle() inside the registerBundles() method of AppKernel. Configuration goes in config.yml under the jquery key, and templates use the bundle's Twig helper to render the script tag.
- How do you configure the jQuery version, CDN domain, or a local jQuery file?
- All options live under the jquery key in config.yml. Set version to change the jQuery release, cdn to point at an alternative CDN domain, and local to a bundle-relative path such as '@AppBundle/Resources/public/js/jquery-1.11.3.min.js' when Google is unreachable. The default version is 1.11.3 and the default local path points inside the bundle itself.
- Does the bundle support async loading and legacy non-HTML5 script tags?
- Yes. Setting async to true adds an async="async" attribute to the emitted script tag, and it defaults to false. Setting html5 to false switches the output to the older type="text/javascript" markup, while the default of true emits a plain HTML5 script tag. These are the only rendering controls the bundle exposes.
- Is evheniy/jquery-bundle still maintained and does it support modern PHP?
- No. The last release was 2016-06-06, the repository has three stars and no dependents, and there is no active maintainer or issue triage. Symfony2 reached end of life in 2018 and the Twig 1.x/2.x APIs bundles of this vintage rely on were removed in Twig 3. Platform constraints target roughly PHP 5.3 through 7.x, so a PHP 8.x install generally requires --ignore-platform-reqs, which is itself a red flag.
- What are the security concerns with loading jQuery from ajax.googleapis.com?
- The bundle hardcodes ajax.googleapis.com and exposes only a version string, so there is no Subresource Integrity, no crossorigin attribute, and no guarantee the referenced file stays pinned. That means a third-party request on every page load, CSP allow-listing work, GDPR and privacy review implications, and a runtime dependency on Google infrastructure. Older jQuery releases of that era also carry documented XSS advisories such as CVE-2020-11022 and CVE-2020-11023, and jQuery 1.x and 2.x are end-of-life upstream.
- What is the Laravel equivalent of this bundle for adding jQuery?
- Use the asset pipeline instead of a package: run npm install jquery and import it from your app.js entry point. On Laravel 10 and later that entry point is compiled by Vite and included with the @vite directive in Blade; older applications use Laravel Mix and mix(). That gives you lockfile-pinned versions, a first-party origin, and no hardcoded CDN dependency.
- How do you migrate off evheniy/jquery-bundle?
- Inventory every template that calls the bundle's Twig helper or reads the jquery.version config key. Lift the version into environment config or an asset manifest entry, then move jQuery into the local asset pipeline via npm or yarn so it is lockfile-pinned and served from your own origin. If a CDN must remain, pin an exact version and add integrity and crossorigin attributes plus a CSP allow-list entry. Finally remove the package from composer.json, delete the config block, and confirm the rendered HTML is identical apart from the script source.