Custom config parameters

All custom config parameters that are defined by Larastan are listed here.

noUnnecessaryCollectionCall, noUnnecessaryCollectionCallOnly, noUnnecessaryCollectionCallExcept

These parameters are related to the NoUnnecessaryCollectionCall rule. You can find the details about these parameters and the rule here.

databaseMigrationsPath

By default, the default Laravel database migration path (database/migrations) is used to scan migration files to understand the table structure and model properties. If you have database migrations in other place than the default, you can use this config parameter to tell Larastan where the database migrations are stored.

You can give absolute paths, or paths relative to the PHPStan config file.

Example

parameters:
    databaseMigrationsPath:
        - app/Domain/DomainA/migrations
        - app/Domain/DomainB/migrations
        - modules/*/migrations

Note: If your migrations are using if statements to conditionally alter database structure (ex: create table only if it's not there, add column only if table exists and column does not etc...) Larastan will assume those if statements evaluate to true and will consider everything from the if body.

disableMigrationScan

default: false

You can disable use this config to disable migration scanning.

Example

parameters:
    disableMigrationScan: true

enableMigrationCache

default: false

Larastan caches parsed migrations and schema dumps between runs to speed up model property inference. Cache files are stored in PHPStan's temp directory and invalidated when migration or schema files change (based on file paths and modification times).

Caching is disabled by default. Set this to true to enable caching. Keep it false if you want to always re-scan migrations or if your temp directory is read-only.

Example

parameters:
    enableMigrationCache: true

squashedMigrationsPath

By default, Larastan will check database/schema directory to find schema dumps. If you have them in other locations or if you have multiple folders, you can use this config option to add them.

Example

parameters:
    squashedMigrationsPath:
        - app/Domain/DomainA/schema
        - app/Domain/DomainB/schema
        - modules/*/schema

PostgreSQL

The default package used to parse the schema dumps, iamcal/sql-parser, is primarily focused on the MySQL dialect. It can read (or rather, try to read) PostgreSQL dumps provided they are in the plain text (and not the 'custom') format, but the mileage may vary as problems have been noted with timestamp columns and lengthy parse time on more complicated dumps.

If you install phpmyadmin/sql-parser (tested with ^5.9), Larastan will automatically switch to that parser at runtime with no additional configuration. When the package is missing or cannot be loaded, Larastan silently falls back to the bundled parser. If the switch does not occur, verify that Composer autoloads have been regenerated (composer dump-autoload) and that only one version of phpmyadmin/sql-parser is present in your dependency tree.

The viable options for PostgreSQL at the moment are:

1. Use the laravel-ide-helper package to write PHPDocs directly to the Models.
2. Use the laravel-migrations-generator to generate migration files (or a singular squashed migration file) for Larastan to scan with the databaseMigrationsPath setting.

disableSchemaScan

default: false

You can disable use this config to disable schema scanning.

Example

parameters:
    disableSchemaScan: true

checkModelProperties

default: false

This config parameter enables the checks for model properties that are passed to methods. You can read the details here.

To enable you can set it to true:

parameters:
    checkModelProperties: true

checkModelAppends

default: true

This config parameter enables the checks the model's $appends property for computed properties. You can read the details here.

To disable you can set it to false:

parameters:
    checkModelAppends: false

parseModelCastsMethod

default: false

By default, Larastan only relies on the return type of the casts() method to infer cast definitions. When this option is enabled, Larastan parses the casts() method body and uses the returned array values to determine cast types.

This can improve inference when you build casts using class constants or concatenation, but it requires parsing the source file thus it might be slower and is disabled by default for that reason.

Example

class User extends Model
{
    public function casts(): array
    {
        return [
            'string' => \Illuminate\Database\Eloquent\Casts\AsStringable::class . ':argument',
        ];
    }
}

parameters:
    parseModelCastsMethod: true

checkConfigTypes

default: false

This config parameter enables the checks for config helper function return type and \Illuminate\Config\Repository::get method return type.

By default, Larastan assumes your config files are under /config directory. It uses config_path function from Laravel to determine this. But if you have unconventional config file structure, you can use configDirectories config parameter to tell Larastan where your config files are stored.

parameters:
    configDirectories:
        - src/config
        - modules/*/config

Example

With this parameter enabled, the following code

// config/auth.php
return [
    'defaults' => [
        'guard' => 'web',
        'passwords' => 'users',
    ],
];

// test.php
echo config('auth.defaults');

would give an error:

Parameter #1 (array{guard: 'web', passwords: 'users'}) of echo cannot be converted to string.

Performance

Larastan parses the config files to be able to understand their structure. But it does this lazily. Only the config files that were accessed during the analysis will be parsed. Also, it has internal caching mechanisms so that one file will not be parsed twice.

Note: Although everything is done lazily, parsing big number of config files might add a little bit of overhead. Use with caution.

generalizeEnvReturnType

default: false

This config parameter, if enabled, will generalize the return type of env function if the default argument is passed. For example:

$foo = env('FOO', 'bar');
\PHPStan\dumpType($foo);

will dump string when the parameter is enabled. Or

$foo = env('FOO', fn() => 'bar');
\PHPStan\dumpType($foo);

will also dump string when the parameter is enabled.

The reasoning behind it is that the default value is always used when the environment variable is not set. And for almost all the cases the default value should be the same type as the actual env variable. So it makes sense to generalize the return type to the type of the default value.