Weave Code
Phpstan Banned Code Laravel Package
ekino/phpstan-banned-code
PHPStan extension that detects banned code in your project, like var_dump, exit, eval, print, shell execution, and other unwanted functions. Configure the exact nodes and functions to block, enforce rules in CI, and keep your codebase clean.
Detect banned code through PHPStan
Frequently asked questions about Phpstan Banned Code
- How do I install ekino/phpstan-banned-code in a Laravel project?
- Install it as a dev dependency with composer require --dev ekino/phpstan-banned-code. If your project already uses phpstan/extension-installer, the extension is registered automatically and you get the default banned-function checks with no configuration. Otherwise add an includes entry pointing to vendor/ekino/phpstan-banned-code/extension.neon in your phpstan.neon. There is no service provider and no runtime footprint, so nothing changes in your application bootstrapping.
- Which PHPStan versions does ekino/phpstan-banned-code support?
- The package tracks PHPStan in lockstep: version 3.x requires PHPStan 2.x, and there is no release that supports two PHPStan majors at once. That means a PHPStan major upgrade is also a breaking upgrade for this package. Pin both ekino/phpstan-banned-code and PHPStan in composer.json and upgrade them together as a pair rather than letting either float.
- What code does ekino/phpstan-banned-code ban by default?
- The default function list covers debug and shell helpers such as dd, dump, var_dump, print_r, debug_backtrace, exec, shell_exec, system, passthru, proc_open and phpinfo. The extension can also flag AST node types rather than function names, which is how it detects echo, print, eval, die/exit and backtick shell execution. All of this is driven by the banned_code parameter block, so you can tighten or widen the list per project.
- How do I configure custom banned functions in phpstan.neon?
- Add a banned_code parameter with a nodes array, where each entry has a type such as Expr_FuncCall and an optional functions list. For example, an Expr_FuncCall entry with functions containing ray, dd and dump flags only those calls. Node entries like Stmt_Echo, Expr_Eval, Expr_Exit, Expr_Print and Expr_ShellExec take functions: null because the node type itself is the rule. The type values correspond to the AST node's getType() result, so any node name PHPStan returns can be used.
- Why can't I add banned code errors to phpstan-baseline.neon?
- Errors emitted by this extension are non-ignorable by default, so they cannot be silently absorbed into phpstan-baseline.neon or inline ignore comments. That is deliberate: it forces offending code to be fixed rather than grandfathered, which is what you want for var_dump, dd and eval. If you need a migration window on a legacy codebase, set non_ignorable: false in your banned_code configuration, then tighten it back once the backlog is cleared.
- Does ekino/phpstan-banned-code work with Larastan?
- Yes. It is a standard PHPStan extension, so it loads alongside Larastan or plain PHPStan and adds rules on top of whatever analysis level you already run. There is no conflict with Larastan rules because this package only inspects AST nodes and function calls. Most Laravel teams add it to an existing PHPStan setup rather than adopting it standalone.
- Does it detect var_dump or dd inside Blade templates?
- No. PHPStan only analyses PHP files, so .blade.php templates are outside its scope and no banned-code rule will catch a dd() left in a view. Compiled views under storage/framework/views should be excluded from analysis anyway, since they are generated. If you need Blade coverage, that requires a separate template linting step, so avoid promising a project has no dd() anywhere based on this tool alone.
- Will it flag exit() in Artisan commands or echo in console output classes?
- Yes, and that is the most common source of false positives on a first run. exit() in Artisan commands, echo in console output helpers, exec in deployment tooling and local debug helpers will all be reported once the corresponding node rules are enabled. Use PHPStan's excludePaths or a narrower analysis scope to carve out the legitimate cases. Note that matching is by function name, so a namespaced project-local helper called dd or dump can also be flagged.
- What does the use_from_tests option do?
- Setting use_from_tests: true reports use statements that import from the Tests namespace inside non-test files. That guards against test factories, fixtures or helper traits leaking into app code where they would break in production autoloading. It is off unless you enable it, and it is one of the few rules here that is specific to application structure rather than to individual function calls.
- Is ekino/phpstan-banned-code a better choice than PHPCS ForbiddenFunctions?
- It is usually more reliable because it works on the AST rather than on token patterns, so it can detect echo, print, eval, exit and backtick shell execution that regex-style sniffs miss. The trade-offs are that it requires an existing PHPStan setup and that it is a small single-vendor project with a modest contributor base, so pin the version you test against. Because it is dev-only, removal is a one-commit change, which keeps the risk confined to CI rather than production.
Weaver
How can I help you explore Laravel packages today?