We have a number of open requests to bring various lint bindings upstream.
Past / Short Term: Currently, dealing with these is a very low priority for me. When I've spent time on them in the past it has almost always been unproductive (i.e., many change requests -- this is at least partially our fault, because writing lint bindings properly is currently too difficult and insufficiently documented), and when we've accepted linters they frequently bring substantial maintenance costs along with them (e.g., see all the broken linters in the table below, which we are largely now solely responsible for maintaining).
Future: The future is that we stop bringing these upstream and offer a packaging/distribution system instead, described in T5055. Additionally, we would:
- fix the issues which make writing linters unnecessarily difficult, technically (e.g., severity/code handling, version handling);
- provide guidance on how to write a proper linter (e.g., how to write tests);
- probably offer some sort of advisory "yeah, we looked at this, it won't FTP all your stuff to foreign states" signing program.
However, this is likely far away. It is complex, it will take a lot of time to get right, and there isn't a great deal of user demand for it.
I'm not sure what we should do with these linters in the mid-term.
A pathway you can take today is to add your linter to Community Resources, and plan to bring it upstream as a real package once that is available. However, installing/managing community linters is difficult and cumbersome, and easier management is presumably the major benefit authors seek by upstreaming linters.
- Lint codes / severities are difficult to get right (T3914, T8474).
- Version requirements are difficult to get right (T9795).
|cppcheck||Minor Issues||T9957, T9734|
|phpcs||Major Issues||T9047, T7170,|
|cslint||Deprecated/Broken||T8978, T8922, T4483|
New Linter Requests
|"Java"||Requested / Patch||T9886, D14632|
|Scalastyle||Patch, No Task||D14145|