It would be useful if .arclint files could be templated and could inherit from other templates. Essentially, I am thinking that we could have a bunch of default templates in the resources/arclint directory of rARC (and allow additional templates to be added via arclint.template-path in the .arcconfig file).
One advantage of this approach is that it would allow us to replace ComprehensiveLintEngine with a simpler JSON template:
ComprehensiveLintEngine
{ "exclude": [ "(^externals/)" ], "linters": { "filename": { "type": "filename" }, "generated": { "type": "generated" }, "jshint": { "type": "jshint", "include": "(\\.js$)" }, "nolint": { "type": "nolint" }, "pep8": { "type": "pep8", "include": "(\\.py$)", "severity": { "E101": "disabled", "E501": "disabled", "W291": "disabled", "W292": "disabled", "W293": "disabled" }, "pyflakes": { "type": "pyflakes", "include": "(\\.py$)" }, "ruby": { "type": "ruby", "include": "(\\.rb$)" }, "text": { "type": "text", "exclude": [ "(\\.cpp$)", "(\\.css$)", "(\\.hpp$)", "(\\.l$)", "(\\.php$)", "(\\.pl$)", "(\\.py$)", "(\\.y$)" ] }, "xhpast": { "type": "xhpast", "include": "(\\.php$)" } } }
There would be some additional complexity with this approach:
- How to handle recursive templates? Should we allow templates to reference other templates? Personally, I don't see any reason against this but it introduces some additional complexity when parsing the .arclint files (to ensure that we don't enter an infinite loop).
- How to merge multiple configurations? My current thinking is to use a deep merge approach (similar to jQuery.extend())?