ESLint comes with several built-in formatters to control the appearance of the linting results, we will probably use the HTML formatter: https://eslint.org/docs/user-guide/formatters/#html
I am happy with this under a couple of conditions...
1) It should be '_' prefixed, i.e. a test you're not supposed to run for every patch release and doesn't need to be 100% respected
2) It should not just crash if eslint and whatever dependencies it has are not available. I imagine that needs node or some such, which I don't want core developers to be forced to install. So it needs to do a clean assertion error when eslint is unavailable.
Thanks! I am not fully sure if it's worth adding a unit test for this as the ESLint configuration file is picked up by PHPStorm automatically and it shows all errors as syntax errors (which is neat, it helps detect many errors early and makes sure the formatting/spacing is perfect). There is a TextMate bundle for it as well and all major IDEs probably have plugins if not out of the box support.
Sorry for making this suggestion without thinking about it fully...
Oh and it can always be run manually by installing eslint using npm (npm install -g eslint) and `cd` to the composr directory, then `eslint .`;
By Guest,
By Guest,
posted
There shouldn't be any undocumented knowledge or undocumented de facto assumptions about people's environment. So if running ESLint becomes a standardised part of the process, that at least needs documented.
However, I don't think it needs to be for now at least.
1) It should be '_' prefixed, i.e. a test you're not supposed to run for every patch release and doesn't need to be 100% respected
2) It should not just crash if eslint and whatever dependencies it has are not available. I imagine that needs node or some such, which I don't want core developers to be forced to install. So it needs to do a clean assertion error when eslint is unavailable.
Sorry for making this suggestion without thinking about it fully...
However, I don't think it needs to be for now at least.