We really need to stop using EClint to validate code styles consistency of the repo's code, for the following reasons:
ECLint development has been officially dead for over two years, and it will soon stop working due to deprecated dependencies or incompatibility with new Node.js versions.
It's quite buggy.
It forces us to distort optimal EditorConifg setting to accommodate validation rules (e.g. set indentation to 1 space instead of two, to allow custom alignments).
It doesn't validate correctly ISO-8859-1 files, which are plentiful in this project.
It's a Node.js app, with all the downsides that come with it (unsafety, outdated dependencies hell, etc.).
Of the above, point 3 is particularly relevant, for it would be ideal to find a code validation tool that uses its own settings file instead of the .editorconfig settings, so that we could decouple it from the EditorConifg rules, which don't always match the validation criteria.
But we can't switch to this tool until the following bug is solved, which prevents its usage within cross platform Git repositories:
editorconfig-checker/editorconfig-checker#164
I.e. if the .editorconfig file contains a rule enforcing native EOLs it will report a false positive:
end_of_line = unset
so we can't use editorconfig-checker until this is fixed — although the tool allows disabling EOL checks, by doing so we won't be validating EOLs consistency in PRs, nor those files types that require a specific EOL.
We could disable EOL checks in editorconfig-checker via its configuration file, and rely on .gitattributes rules instead, but the latter only work when there are appropriate Git settings, so invalid EOLs could end up in the repository, since the Travis CI task won't be validating them (need to weight the pros and cons of this, after all I've submitted the bug report in April and it's still unfixed, and EClint is becoming more problematic as Node.js gets updated).
NOTE — EditorConfig has rejected the proposal to introduce end_of_line = native, so to only viable alternative is to unset its value and rely on .gitattributes rules instead (see editorconfig/editorconfig#226).
We really need to stop using EClint to validate code styles consistency of the repo's code, for the following reasons:
Of the above, point 3 is particularly relevant, for it would be ideal to find a code validation tool that uses its own settings file instead of the
.editorconfigsettings, so that we could decouple it from the EditorConifg rules, which don't always match the validation criteria.(see also: alan-if/alan-docs#79)
Editorconfig-Checker
The only viable alternative to EClint which I've found is editorconfig-checker (also available as NPM package), which I've been testing locally for over a year.
But we can't switch to this tool until the following bug is solved, which prevents its usage within cross platform Git repositories:
editorconfig-checker/editorconfig-checker#164
I.e. if the
.editorconfigfile contains a rule enforcing native EOLs it will report a false positive:so we can't use editorconfig-checker until this is fixed — although the tool allows disabling EOL checks, by doing so we won't be validating EOLs consistency in PRs, nor those files types that require a specific EOL.
We could disable EOL checks in editorconfig-checker via its configuration file, and rely on
.gitattributesrules instead, but the latter only work when there are appropriate Git settings, so invalid EOLs could end up in the repository, since the Travis CI task won't be validating them (need to weight the pros and cons of this, after all I've submitted the bug report in April and it's still unfixed, and EClint is becoming more problematic as Node.js gets updated).