Project file

[mkusher]

Proposal

Project file is a yaml(e.g. .padawan.yml) configuration for a project.

Structure

php: 7
plugins:
    Mkusher\SymfonyPlugin:
    Someone\SomepackagePlugin:
        extra_option_for_somepackagePlugin: 1
exclude: ['app/bootstrap.php.cache', 'app/cache/*']
cache_dir: '.padawan'

here we have 3 sections:

1. plugins - plugins you want to be enabled for this project
2. exclude - files or folders you want to exclude from being indexed
3. cache_dir - folder for padawan.php cache for this project
4. php - version of php being used for running padawan. Could be 5 or 7. php5.* will use nikic/PHP-Parser and 7 will use built-in AST builder.

Editors' plugins

Before editors were looking for composer.json file, now they will have to look for .padawan.yml first and only then look for composer.json.

[voronkovich]

👍

[msjyoo]

Maybe this should be stored inside the .padawan folder?

[mkusher]

@sekjun9878 this file is not autogenerated by padawan.php, you should create it manually. So for a new project your variant will need extra step - make dir .padawan :)

[mkusher]

updated proposal: added php prop
php - version of php being used for running padawan. Could be 5 or 7. php 5.* will use nikic/PHP-Parser and php 7 will use built-in AST builder.

[msjyoo]

@mkusher php7 has a built-in ast node builder?

[mkusher]

@sekjun9878 https://github.com/nikic/php-ast

[msjyoo]

@mkusher That however introduces an additional dependency on the php-ast extension (and therefore a need for a custom PHP build)? I guess it depends on the result of https://wiki.php.net/rfc/parser-extension-api but for the forseeable future it looks like just using PHP-Parser seems a better choice.

[dantleech]

+1 would also be good to cascade back to a global configuration so I can f.e. ignore nested vendor files **/vendor