Configuration file handling

[enygma]

It's been suggested in #10 that a configuration file should be added to allow for more customization than just the command line options allow.

Considerations:

• Format (JSON, XML, YAML, INI)
• What functionality needs to be configured in it

[hanneskod]

I have some thoughts on this: As a first step I want to move some of the complexity of ScanCommand to a ConfigManager. The manager can be written to handle a ConfigFileInterface, preparing for the actual implementation in a format-agnostic way. I don't think doing this will add to the overall complexity of the project, quite the opposite I think it will make for a better division of concerns.

Any more thoughts on format and structure of the config file?

[redbeardcreator]

My only thought is it should mirror the error suppression annotations from #52.

[hanneskod]

Here is a suggested configuration file structure. I like json because it is so simple to parse... We also need to decide on a default conf file name. I suggest .psecio-parse.json.

{
    "paths": ["pathOne", "pathTwo"],
    "ignore-paths": ["pathTwo/subpath"],
    "extensions": ["php"],
    "whitelist-rules": ["rulename"],
    "blacklist-rules": ["rulename"],
    "disable-annotations": true,
    "format": "dots",
    "verbose": true,
    "debug": true,
    "ansi": true
}

What do you think? @enygma @redbeardcreator

[redbeardcreator]

It looks good to me. I also prefer JSON. But Any format is fine as long as it's consistent.

[enygma]

yeah, looks good to me too...is the "extensions" setting just to determine the file extensions to check? Would it ever really need to be anything other than .php?

[redbeardcreator]

I have some older projects that used .inc. I believe at the time it was a fairly common practice. Of course, that was PHP 4 when I was able to crash PHP by using too many pass-by-reference calls. But I still have .inc files in the field.