Final Newline Bug under Windows

[tajmone]

Under Windows, editorconfig-checker raises false-positive errors for final new lines in files that are set as insert_final_newline = unset or don't have that setting at all — i.e. it seems a problem with the internal default EOL expectation for final new lines.

Because the EditorConfig specification refuses to add support for native EOLs, in cross-platform Git repositories, we need to configure those file extensions as end_of_line = unset, and rely on .gitattributes settings to validate them at commit time.

But under Windows, editorconfig-checker always reports the following error for files that are using native EOL (i.e. CRLF locally, under Win OS) and which are configured as end_of_line = unset in .editorconfig:

Wrong line endings or new final newline

Even if I comment the end_of_line = unset line I get the same error. The only way to pass validation is to use end_of_line = crlf instead — which is going to mess up these files under Linux and macOS.

It seems to be a problem with the default editorconfig-checker settings for EOLs, which might be taking over whenever the end_of_line is missing or = unset.

If I disable the EOL checks via the -disable-end-of-line option, the errors go away. So this problem seem to only affect ending line checks, not EOLs in the file body.

It might also be a good idea to add an extra editorconfig-checker setting/option to support native EOLs during validation, regardless of the fact that the original EditorConfig spec doesn't support it, since this feature makes sense when validating projects.

[tajmone]

Any ETA for this fix?

This single issue is the only real blocker for using editorconfig-checker to validate Git repositories right now.

Disabling EOL checks is not a viable option since some file types need to enforce a specific EOL and that option would have global effect.

[mstruebing]

If I remember correctly I don't think that we are currently supporting unset.
I need to look into this and probably have some time this weekend.

[tajmone]

I need to look into this and probably have some time this weekend.

Thanks a lot, I really appreciate it.

[mstruebing]

All of the love goes straight to @KylePolansky :)

[tajmone]

Update NPM Package?

It's great to see that the Windows EOL bug was fixed. Unfortunately the NPM package still lags behind to core 2.3.5.

Any chances you could update the NPM package so we can use it in production? Thanks.

[tajmone]

As of version 2.7.2, I'm still experiencing this problem if I keep end_of_line = unset, but it works fine if I just omit the setting.

The problem is that if there is a catch-all pattern definition (*.*) that defines some default settings for all files, and then we need to overwrite the end_of_line setting for a specific pattern with value unset to mimic Git "native EOL" then ec validation fails — unfortunately, many repositories which assume Linux as the default dev env will define global patterns with end_of_line = lf, and then unset for extensions which should use native EOL.

Unfortunately, at the EditorConfig project they are not willing to consider end_of_line = native as a valid choice (Git is not a priority), so there's currently no proper way of handling native EOLs except by unsetting end_of_line.

Editorconfig-checker could obviate to this limitation by either:

• Treating end_of_line = unset as meaning "native EOL", instead of "any EOL".

• Implementing an editorconfig-checker specific option to handle this, e.g.

  ec_end_of_line = native
  

  where the ec_end_of_line entry overrides whatever value there is for end_of_line, while it's ignored by other EditorConfig tools. So, it would be possible to have in a same configuration:

  [*.md]
  end_of_line = unset
  ec_end_of_line = native
  

I personally would prefer the former solution, since (assuming version control as a main use-case for editorconfig-checker) it would enforce EOL consistency — whereas unset if meant to allow freely mixing LF, CRLF and even CR, which is hardly a desired setting for those seeking code consistency (albeit it might be a legitimate case, e.g. in test-suites).

For such cases, editorconfig-checker could support the non-official value any (end_of_line = any) to allow free-mixing of EOLs, rather than native.