[EditorConfig] "insert_final_newline = false" doesn't produce warnings in files that contain final newlines.

[EricDunsworth]

According to the EditorConfig website's supported properties section and editorconfig/editorconfig#269 (comment), insert_final_newline = false is supposed to ensure a file doesn't end with a final newline. The EditorConfig editor plugins I tried also work in that way - they strip out final newlines when saving files associated to .editorconfig files that have that property set to false.

However, lintspaces' equivalent newline property doesn't work in the same way. According to the newline option's documentation, it's solely designed to check for the the presence of final newlines and isn't capable of doing the opposite.

Since lintspaces' .editorconfig option works by remapping insert_final_newline to newline, that causes a clash between both interpretations.

Could something be done to make lintspaces' .editorconfig option follow that format's more aggressive interpretation of insert_final_newline = false?

Code/Output samples...
The samples below demonstrate how lintspaces currently reacts to insert_final_newline = false when a file contains a final newline.

.editorconfig

root = true

[*]
insert_final_newline = false

test.txt (contains a final newline)

test

check.js

var Validator = require('lintspaces');

var validator = new Validator({editorconfig: '.editorconfig'});
validator.validate('test.txt');

var results = validator.getInvalidFiles();

//Derived from https://stackoverflow.com/a/10729284
const util = require('util');

console.log(util.inspect(results, {showHidden: false, depth: null}));

Output when running node check.js in Windows:

{}

Expected output of node check.js:

{ 'test.txt':
   { '2':
      [ ValidationError {
          line: 2,
          code: 'NEWLINE_AMOUNT',
          type: 'warning',
          message: 'Unexpected additional newlines at the end of the file.' } ]
} }

[schorfES]

Hi @EricDunsworth,
thank you for this detailed issue. You're totally right that lintspaces should react differently when getting the setting for newlines from .editorconfig (according the expected behaviour) or from the regular config/rcconfig.
I think we need to extend the configuration to allow different kinds of error reportings depending on the origin of settings. As you can see settings from the editorconfig are more relevant than other ones which allows us to overwrite the default on/off-behaviours.
I will fix this problem in a future release. However, if you need a faster fix, I would be very happy to accept a PR to solve this.

[Bartheleway]

I agree with @EricDunsworth, documentation state that

insert_final_newline: set to true to ensure file ends with a newline when saving and false to ensure it doesn't

I will expect these behavior

Value of setting	Kind of check
undefined	no check
unset	no check
true	blank line must be present
false	no blank line at EOF

[schorfES]

I agree with both of you. Adding the ability to check the opposite, similar to how EditorConfig does, would indeed be a nice improvement for this check (and a step towards version 1.0). We need to enhance this check to validate the opposite condition as well.

However, I want to emphasize that the project’s intention is not to replicate the entire feature set of EditorConfig 1:1. Changing this behavior would introduce a breaking change to the newline option, which was initially designed differently (true = enabled, false = no check/disabled). If we proceed with this suggested behavior, I believe the project should migrate all available settings to follow a consistent pattern:

Value of setting	Kind of check	Comment
undefined	disabled / no check
true	enabled / allowed
false	disabled / disallowed	May not apply to most options
'unset'	disabled / no check	Redundant; should not be introduced as it duplicates undefined

If you agree, we could discuss a roadmap for the required changes (perhaps in a new issue).

[Bartheleway]

Personally, I find the behavior of "insert_final_newline" vs "trim_trailing_whitespace" not consistent. For whitespace, false means no trim but doesn't means add an extra space at the end of line. For final newline, as said, false means remove blank lines at EOF.

I got your point, this package is not an editorconfig checker but a more widely "space" checker. In that matter, I agree with you that changing the package behavior because we accept editorconfig as one possible configuration option feels incorrect.
On the other hand, if the package accept editorconfig as one possible configuration option, then it should lint according to editorconfig specs (when loading config from it)

Could we make an exception behavior change when loading an editor config? Or maybe create another configuration option like trimBlankLines or use the newlineMaximum: 0 as it already exist and only consider newlineMaximum: false as deactivated.

[schorfES]

I think we are all on the same page. The ability to test for both conditions (whether there is explicitly a newline or explicitly no newline at the end of a file) needs to be added for the newline option. This will bring Lintspaces closer to EditorConfig’s behavior for this setting, making it more consistent when using EditorConfig as a configuration source for Lintspaces. 👍

Could we make an exception behavior change when loading an editor config? Or maybe create another configuration option like trimBlankLines or use the newlineMaximum: 0 as it already exist and only consider newlineMaximum: false as deactivated.

I’m not entirely sure I understand what you’re suggesting, but I assume you mean setting newlineMaximum=0 when insert_final_newline=false is specified by EditorConfig? Doing so would do the job for the last line but likely break the expected behavior of newlineMaximum, as it validates all the newlines between code blocks as well. Please also consider that Lintspaces supports configuration from multiple sources simultaneously by having a load order (defaults -> constructor parameters -> RC config -> EditorConfig). If one setting implicitly affects another, it could lead to confusing behavior.

Personally, I find the behavior of "insert_final_newline" vs "trim_trailing_whitespace" not consistent. For whitespace, false means no trim but doesn't means add an extra space at the end of line. For final newline, as said, false means remove blank lines at EOF.

I’ve also been thinking about whether there’s a need to also consider other EditorConfig options. The expected behavior really depends on the nature of each option. For insert_final_newline, the goal is to control whether or not a final newline exists at the end of the file, while for trim_trailing_whitespace, the intention is to explicitly remove spaces at line endings. I can’t think of any scenario where you would want to add a space at the end of each line… 🤔 That's why there is basically not need to add the opposite behaviour.

[Bartheleway]

Oh crap, you are right, I didn't see that newlineMaximum was also used between blocks. Then I guess we have no other choice than to make a trimFinalBlankLine.

newline	trimFinalBlankLine	presence of 1 or more blank lines at end	result
false	false	yes / no	pass
true	false	yes	pass
true	false	no	warn / fail
false	true	yes	warn / fail
false	true	no	pass
true	true	yes / no	inconsistent config

I feel it brings a new functionality which is generic and not linked to editorconfig but allow to apply correctly editorconfig configuration :)