vscode-laravel-extra-intellisense: completion that runs your Laravel app to find out

Where the extension gets its data

The design decision that explains everything else in this extension is stated in the README's security note: it runs your Laravel application automatically and periodically to get the information needed to provide autocomplete. Nothing is parsed out of your source files. Route lists, resolved config values and the actual set of translations are all read by executing PHP inside the app and asking Laravel what it knows.

The default command makes that concrete. `LaravelExtraIntellisense.phpCommand` defaults to `php -r "{code}"`, where the extension generates the PHP, wraps it in quotes and substitutes it into that template. Two companion settings keep the two sides of that boundary straight. `LaravelExtraIntellisense.basePath` is where the extension reads files from, and `LaravelExtraIntellisense.basePathForCode` is the path used for `require_once` inside the generated PHP. A path beginning with `.` such as `./src` is treated as relative, anything else as absolute, which is what makes monorepo layouts work.

`package.json` shows the rest of the plumbing. The extension activates on `onLanguage:php` and `onLanguage:blade`, requires VS Code `^1.83.0`, ships as `./dist/extension.js`, and is built with `webpack.config.js` from TypeScript sources in `src/`. The version there is 0.7.4.

What you get in a Blade file

The feature list is long enough that it is worth grouping. Route names and route parameters come first, and the release notes say route action autocomplete has filled in controller actions under `app\Http\Controllers` since 0.1.x, with a Linux-specific route bug fixed along the way. Views and their variables are the other half, covering view functions including `markdown`, section and stack autocomplete, and a file watcher rather than a save event so changes are detected faster.

Then there is the framework surface: config keys, translation keys with nested support added in 0.6.x, Mix and Vite helper functions, validation rules, env values, route middleware, `asset`, `can` and `cannot`, and Blade directives, which arrived most recently in 0.6.x and can be switched off. Model attribute completion is present but labelled beta in the README, which is the honest word for type inference on a variable in a template.

Anything the framework computes at runtime is fair game for this approach, and that is exactly why it can offer things a static extension cannot. What it cannot offer is knowledge of code paths the app never executes.

The settings that decide what gets indexed

Model attribute completion needs help, because inferring a variable's type inside a Blade template is hard. `LaravelExtraIntellisense.modelsPaths` defaults to `["app", "app/Models"]`, which covers the pre-11.x and 11.x layouts at once. `LaravelExtraIntellisense.modelVariables` maps variable names to classes when inference fails:

LaravelExtraIntellisense.modelVariables": {
    "discountedProduct": "App\\Models\\Product"
}

By default every `camelCase` and `snake_case` spelling of a model name works, so `$productDiscount` and `$product_discount` both resolve against `App\Models\ProductDiscount` without configuration. Case handling is a separate pair of settings: `modelAttributeCase` accepts `snake_case`, `camelCase` or `default` for attribute names, and `modelAccessorCase` does the same for accessors.

Custom validation rules are the setting most projects will touch first, because application-specific rules cannot be inferred:

LaravelExtraIntellisense.customValidationRules": {
    "mobile": "mobile",
    "distance_gt": "distance_gt:${0:1km}"
}

Four settings exist purely to turn things off: `disableBlade`, `disableAuth` for the `can` and `cannot` completions, `disableErrorAlert` to hide the alerts raised when data cannot be fetched, and `viewDirectorySeparator` if you prefer `/` over `.` when typing view names.

Pointing it at Docker or Sail

If your application runs in a container, the default `php -r` command finds nothing. The README gives a working Laradock configuration, which changes both the command and the path used inside the generated code:

LaravelExtraIntellisense.phpCommand": "docker exec -w /var/www/your-project -u laradock laradock_workspace_1 php -r \"{code}\"",
LaravelExtraIntellisense.basePathForCode": "/var/www/your-project"

Laravel Sail has its own sample, using `docker-compose exec` and noting that `laravel.test` is the default service name:

LaravelExtraIntellisense.basePathForCode": "/var/www/html",
LaravelExtraIntellisense.phpCommand": "docker-compose exec -w /var/www/html YOUR_SERVICE_NAME php -r \"{code}\""

The README says the same mechanism works with other Docker images or other virtual machines, which is the useful generalisation: the template only has to end in something that can run PHP, and the two path settings let the editor's view of the filesystem differ from the container's. There is also support for workspaces with multiple directories, added in 0.6.x.

The security note deserves more than a skim

Most extension READMEs do not have a section like this one. It says the extension runs your application automatically and periodically, that if you see unknown errors in your log you should check whether it is the cause, and that if you are writing sensitive code in service providers you should disable the extension temporarily to prevent the application executing when you do not want it to.

That is an unusually candid warning, and it follows directly from the design. A command-line application with a side effect on boot is being started on a timer by your editor, so anything that runs on boot runs repeatedly and unattended. The mitigations are practical: keep the generated commands read-only, scope the paths with `basePath`, use the Docker form so the run happens inside the container you already trust, and disable the extension while touching provider code.

The 0.2.x notes record that PHP commands were converted to async functions to stop the extension host becoming unresponsive, and that auto-retry was removed from all providers because it caused performance problems. Those two changes are a fair sketch of the failure modes: a synchronous framework boot is slow, and retrying makes it slower. `SECURITY.md` sits at the top of the repository alongside the note in the README.

Maintenance signals and where the docs stop

The repository is TypeScript, MIT licensed, with 4,215 stars, 60 forks and 46 open issues. It is not archived, and the last push was on 2026-07-15, so it is a few months behind that date rather than abandoned. The `src/` directory, `webpack.config.js`, `tsconfig.json` and a `tslint.json` that predates the ESLint migration in the VS Code extension toolchain all point to a conventional extension layout that has not been restructured in a while.

The version number and the release notes disagree in an interesting way. `package.json` says 0.7.4, while the README's release notes stop at 0.6.x. That gap tells you where the recent work is described: the changelog you would read on the marketplace or the extension page is ahead of the README, which is a common pattern for an extension with a large user base and a maintainer with limited time.

The README also closes with a recommended extensions section that is cut off in what is published, so the honest summary is that configuration and features are documented well, and the relationship to other Laravel tooling is not. For that, the marketplace page is where to look next.

Editorial conclusion

Laravel Extra Intellisense solves a problem static analysis cannot: a route list only exists after the framework boots, and a view only exists on disk if it has been used. Running the application is a blunt way to get that truth, and it is also why the project ships a security note telling you to turn it off while writing sensitive service providers. The payoff is concrete. Route names, route parameters, view names and their variables, config keys, translation keys, validation rules, `can` and `cannot`, env values, middlewares, asset helpers, Mix and Vite functions, and Blade directives all resolve from the running app instead of from guesses. The cost is that your editor is now booting your framework on a schedule, and the Docker and Sail configurations exist because that is not always convenient. Start with the defaults, which index `app` and `app/Models`, add a custom validation rule or two, and only reach for `LaravelExtraIntellisense.phpCommand` once your project runs somewhere other than your own working directory.

Frequently asked questions

Official sources

1. amir9480/vscode-laravel-extra-intellisense on GitHub
2. Issues
3. License: MIT
4. Project website
5. README