Angularjs Symfony2 Bundle Laravel Package

Getting Started

Install the bundle through Composer, then register it in the classic Symfony2 kernel:

composer require sunra/angularjs-symfony2-bundle

// app/AppKernel.php
public function registerBundles()
{
    $bundles = array(
        // ...
        new Sunra\AngularJSBundle\SunraAngularJSBundle(),
    );
}

The bundle is essentially a Composer-packaged distribution of AngularJS plus a set of commonly-paired libraries (angular-resource, angular-route, angular-cookies, angular-sanitize, angular-animate, angular-ui-router / ui-bootstrap variants, etc.) exposed as Symfony bundle assets under Resources/public/. Your first use case is therefore: publish the static assets and reference them from a template.

php app/console assets:install web --symlink

Then in your Twig template:

<script src="{{ asset('bundles/sunraangularjs/js/angular.min.js') }}"></script>
<script src="{{ asset('bundles/sunraangularjs/js/angular-route.min.js') }}"></script>

Where to look first:

1. The bundle's Resources/views/ for any provided base/layout template that already includes the script tags.
2. The bundle's Resources/public/ directory listing to see exactly which library files and versions are shipped.
3. composer.json / composer.lock to pin down the exact AngularJS version (1.x series), since that dictates which API behaviors you can rely on.

Then wire a Symfony controller that returns JSON and point an Angular $http call at it — that is the canonical first integration.

Implementation Patterns

Asset publishing per environment. Use assets:install --symlink in dev for fast iteration, and assets:install (copy) in production deploys. Because the assets come from a vendor bundle, they must be re-installed after every composer install/update — bake assets:install into your deploy script, not your build step.

Selective library includes. Do not include every shipped library. Build a small Twig layout partial (_angular_assets.html.twig) that lists only the modules your app actually uses, and {% include %} it from the base template. This avoids shipping ui-bootstrap or angular-touch if you never use them.

Bundle-scoped Angular app. Keep your own Angular code in your own bundle (src/AppBundle/Resources/public/js/app.js) and declare the module with the libraries you included:

angular.module('app', ['ngRoute', 'ngResource'])
  .config(['$routeProvider', function ($routeProvider) { /* ... */ }]);

Then reference it with {{ asset('bundles/app/js/app.js') }} — keeping third-party libs and app code in separate bundles makes upgrading/removing the packaged libs easier later.

API + Angular in one Symfony app. Pair the bundle's frontend assets with Symfony controllers that return JsonResponse, and expose routes via normal Symfony routing. A typical pattern is a thin "API" controller area authenticated with a session or a token, with Angular $http configured with a transformRequest to add the CSRF token if you use forms.

Assetic-era integration. If the project is old enough to still use Assetic, you can pull the bundle assets into an Assetic collection rather than using asset() tags directly — but this only matters for pre-Symfony-3 projects. On any newer stack, prefer leaving Assetic out and just using asset() or, better, Webpack Encore with your own npm-installed AngularJS.

Version consistency via the lock file. The primary value of this bundle historically was that composer.lock pinned the entire AngularJS library stack together. If you inherit a project using it, treat the composer lock as the source of truth for frontend lib versions and avoid hand-downloading additional AngularJS plugins of a different minor version.

Gotchas and Tips

This is an EOL stack. AngularJS 1.x reached end-of-life in December 2021 and receives no security fixes; the bundle itself has had no release since May 2016 and has zero dependents. Do not introduce it into new projects, and treat it as a migration target if you find it in an existing codebase.

No Symfony Flex support. The bundle predates Flex and the config/bundles.php convention. On Symfony 4+ you must register it manually in config/bundles.php (and confirm the bundle class autoloads cleanly), or the whole thing is dead weight — most 4+/5+ projects should just copy the needed JS out of vendor/ and manage assets with Encore instead.

Missing assets after deploy. Because assets live under vendor/, a composer install --no-scripts or a deploy that forgets assets:install leaves web/bundles/sunraangularjs/ empty and yields 404s in the browser while the page renders fine. This is the most common production-only failure. Verify the directory exists and contains files before debugging anything else.

Symlinked assets and cache. With --symlink, clearing the Symfony cache or rebuilding the web/ directory can orphan symlinks. If the bundle's version upgrades, the symlink may point at a directory whose file list changed — re-run assets:install after any composer update.

AngularJS 1.5 → 1.6 behavior cliffs. The version shipped here is fixed; know which one you got. If it is ≥1.6, $http legacy .success()/.error() callbacks are gone, $location gained a default hash prefix (!#), and ngModel added $pending/$validators semantics. Code samples copied from older tutorials will fail silently or break routing.

Template overrides are fragile. If you rely on the bundle's provided base Twig template and override blocks to change which scripts load, cross-version template structure changes will break your overrides. Prefer maintaining your own layout and referencing individual asset paths — that decouples you from the bundle's template.

Extension point is the fork. There is no meaningful service or configuration surface for adding newer libraries or bumping AngularJS; the practical extension path is to fork the repo, update the contents of Resources/public/, and switch your composer.json to a VCS repository entry. Combine that with a plan to move to npm/Encore, since you will own the fork indefinitely.

Debugging tips. Use app/console assets:install --symlink with verbose output to confirm which files were published; inspect the browser Network tab to distinguish a missing asset (404 on bundles/sunraangularjs/...) from a module-load error (200 but angular.module unknown in the console, usually a missing ngX include); and check that script tags are ordered so angular.min.js loads before any angular-*.js modules.