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:
```lang=json, name=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 [[http://api.jquery.com/jquery.extend/ | jQuery.extend()]])?