Ngcommands Laravel Package

Getting Started

1. Install (package targets Laravel 5.x era; 2.0.0 only changes generated templates):

   composer require laraplate/ngcommands
   

2. Register the service provider — this predates package auto-discovery, so on Laravel ≤5.4 add it manually to config/app.php:

   'providers' => [
       // ...
       Laraplate\NgCommands\NgCommandsServiceProvider::class,
   ],
   

3. Publish the config so you control where generated files land:

   php artisan vendor:publish --provider="Laraplate\NgCommands\NgCommandsServiceProvider"
   

   Look for a config file (typically config/ngcommands.php) with an output path — set it to your assets directory, e.g. resources/assets/js/app.

4. Discover commands: the generators are registered under an ng: namespace. Run:

   php artisan list | grep ng
   

   You should see entries for controllers, services, directives, modules, routes, and filters.

5. First use case — scaffold a controller:

   php artisan ng:controller UsersController
   

   As of 2.0.0 the skeleton is ES6 (arrow functions / class + static $inject style rather than the old ES5 function($scope) form) and file extensions are now consistent across all generators. Open the file, confirm it matches your conventions, and check it against your transpile step before committing.

Where to look first: the published config file (output path, naming), then the generated stub output itself — 2.0.0 changed the templates, so re-read a generated file rather than assuming it matches 1.x output. Then the command list.

Implementation Patterns

Pair generator output with Laravel resource routes. The natural workflow is: php artisan make:controller UsersController --resource alongside php artisan ng:controller UsersController. Keep a one-to-one mapping between Laravel controllers and Angular controllers so feature ownership stays obvious in the repo.

Generate the component trio per feature. For a users feature, generate:

php artisan ng:module users
php artisan ng:controller UsersController
php artisan ng:service usersService

Then add the controller/service to the generated module's dependency list. Most 2016-era generators don't auto-wire modules, so plan on a quick manual append.

Directory-per-feature layout. Point the config output at resources/assets/js/app and create features under subdirectories (app/users/). The generators usually accept a path-like name, so ng:controller users/UsersController produces app/users/UsersController.js. This keeps the flat AngularJS 1.x tree navigable.

Add a transpile step (new in 2.0.0). ES6 templates are not browser-ready for the older targets this package was built for. Route the output directory through Babel (or your bundler's ES6 loader) before it reaches the browser:

// gulpfile / webpack / vite config
gulp.src('resources/assets/js/app/**/*.js')
    .pipe(babel({ presets: ['@babel/preset-env'] }))

If you already have Babel in the pipeline, this is a one-line include of the new output directory. If you don't, add it before generating a large batch.

Custom stubs for team conventions. If the default ES6 stubs don't match your style (IIFE wrappers, controllerAs syntax, decorators, TypeScript), publish or override the stub directory and point config at it. This is the single highest-leverage customization — it means every generated file is already lint-clean and already transpiler-friendly.

Batch generation via a shell script. Since generation is non-interactive, wrap common scaffolds in a script:

for f in users orders products; do
  php artisan ng:controller "${f^}Controller"
  php artisan ng:service "${f}Service"
done

Commit the script alongside the app so new team members can regenerate consistently.

Integrate with the build pipeline. In the Elixir/Gulp era this meant mix.scripts(...) globbing resources/assets/js/app/**/*.js. On a modern stack, swap to Vite or webpack with the same glob — but now wrap it with Babel if your browser targets predate ES2015. The generator only writes files — it doesn't touch the build config, so wire Babel + glob up once and forget it.

Pair with API resources. When the Laravel side exposes a JSON API (Route::resource + Api\UsersController), use the generator to create a matching Angular service that encapsulates the $http calls. That keeps the client's data-access layer consistent across features.

Migrating from 1.x output. Because 2.0.0 is a major bump with different templates and unified extensions, don't regenerate in place. Regenerate into a temp directory, diff against the existing tree, and port the differences manually — otherwise you'll silently overwrite hand-edited files.

Gotchas and Tips

2.0.0 is a breaking change for regenerated files. Existing 1.x-generated files won't match the new ES6 stubs, and the extension cleanup may rename files. Anything that hardcodes a .js (or other) extension in a build glob, require/import, or asset manifest should be re-checked. Diff before you regenerate.

ES6 output now implies a build requirement. Older IE/legacy Safari targets cannot run the generated templates raw. Either add Babel to the pipeline (recommended) or override the stubs with an ES5 variant — but pick one deliberately, because mixing ES6 and ES5 stubs across the same app is a fast route to inconsistent linting.

No auto-discovery. On Laravel 5.5+ the provider may be discoverable, but don't count on it for a 2016 package — verify with php artisan list | grep ng, and if commands are missing, register manually. composer dump-autoload after install if you hit class-not-found.

AngularJS 1.x only. Despite the repo name suggesting generic "Angular," this generates AngularJS (1.x) code — $scope, $http, angular.module(...). It is not compatible with Angular 2+ / TypeScript. ES6 templates do not change that; they're ES6 syntax for AngularJS 1.x, not modern Angular.

Dependency pinning is the #1 install blocker. The illuminate/support constraint is from early 2016 and will conflict with anything recent. Options: install into a Laravel 5.1–5.4 app, or fork the composer.json constraints locally. Do not expect composer require to succeed cleanly on Laravel 8+ — and note that 2.0.0 did not relax these constraints.

DI must be minification-safe. ES6 class controllers using static $inject = ['$scope', '$http'] are safe; arrow-function or bare class constructor($scope, $http) forms are not. Audit the new 2.0.0 stubs once before wiring up a minifier, and if they're unsafe, fix it in your custom stub rather than in each generated file.

Overwrite behavior is silent. Most of these generators use File::put without confirmation. Before running a batch — especially after this major version — git commit first. Consider a naming convention that avoids collisions with manual files.

Naming/casing is naive. ng:controller usersController and UsersController may resolve to different file names and class names. Prefer PascalCase for controllers and camelCase for services, and always git status after generation to see what actually got written — doubly so now that extensions are normalized.

Config caching bites. If you change the output path in config and see no effect, run php artisan config:cache (or config:clear). In dev, keep config uncached to avoid confusion.

Extension consistency is convenient but not free. Unified extensions mean a single glob now catches every generated component type — good — but it also means a broad glob will pick up modules and routes you may have meant to load separately. Verify load order (module → components → routes) after the first post-2.0.0 generation.

Extension point is the stub directory. Adding new component types (filters, factories, interceptors) means adding a stub file plus a command registration — cheaper to fork the package and maintain a small branch than to wrap it. This is now more attractive: forking lets you keep the 2.0.0 ES6 templates while pinning them against future surprises. If the package is unmaintained in your context, a 30-line custom Artisan command calling File::put($path, view($stub, $data)) gives you the same benefit with far less baggage.

Zero dependents and a small release history mean no community fixes for edge cases you hit. The 2.0.0 changelog is three lines; read the actual stub files (they're small) before relying on the "ES6" claim for anything specific — the exact syntax used varies by generator. Debugging is straightforward once you locate the stub path.