a-r-m-i-n / editorconfig-cli Goto Github PK

Must be -c not -s

Currently, only the .gitignore in given working directory is evaluated. When child directories contain .gitignore files, whose contents will be ignored.

Follow up of #4

Currently the folders "vendor" and "node_modules" are hardcoded.

Because PHP 7.4 support is already over, this version does not need to get supported anymore. Same goes for PHP 8.0, which is about to end. Thinking about to raising the required PHP version to 8.2 and release all this with new major version 2.0.0.

Also, PHP 8.3 is out, so the automated tests should cover this case.

And, thanks to new PHP 8 features, some code refactorings should also get applied. And Symfony v7 components should also get supported.

Hi Armin,

according to the docs (https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties#supported-by-a-limited-number-of-editors), off is a valid value for setting max_line_length which should result in no rules being applied regarding line lengths.

EDIT

Forgot to mention that using off currently leads to this exception:

In MaxLineLength.php line 24:
                                              
  is not a valid value for 'max_line_length'                                         

Thanks for this great tool.
Alex

Currently, the strict mode can only get applied to all or none files. Some file types, like JSON or YAML should always get indented as defined, because there are no special linters (eg. JS or PHP) which allow exceptions.

So, instead of making strict mode option boolean, it should get converted to a string, which allows to define a comma-separated list of file patterns, which should have strict mode enabled.

Then, those variants of using the option exist:

• No strict mode option given (= strict mode off)
• Strict mode given with empty string (= strict mode on)
• Strict mode given with comma separated string (=strict mode only applies to given file patterns)

It would be great if there was a config file like with php-cs-fixer where the scanned directories can be defined with an instance of symfony/finder.

When a json file for example has mixed indentions (spaces and tabs) the indention rule does not detect an issue.

In Rules\Validator.php in createValidateFileResult the $filePath variable may be an empty string, when the file contains special chars, like umlauts.

For example, the file Sonne-weiß.svg gets resolved to

by SplFileInfo (Finder).

This filename does not exist and therefore realpath will create an empty string.

max_line_length is part of the rule set but not skippable.

Hi Armin,

I just used version 1.2.0 on my code base with this config:

# EditorConfig is awesome: http://EditorConfig.org

# top-most EditorConfig file
root = true

# Unix-style newlines with a newline ending every file
[*]
charset = utf-8
end_of_line = LF
insert_final_newline = true
trim_trailing_whitespace = true

[*.php]
indent_style = space
indent_size = 4

After "fixing" my code base, all line feeds are removed, i.e. all files only contain 1 line afterwards. Example:

<?php

declare(strict_types=1);

namespace App\Controller;

...

is squashed into one line like this:

<?phpdeclare(strict_types=1);namespace App\Controller;...

Any idea what might be the issue?

Have a nice day,
Alex

Currently it is not possible to define all options and argument in a separate file. This feature would change that.

Then, all options and arguments can get defined there and the call for EditorConfigCLI would be: vendor/bin/ec --config path/to/ec-config.php

Additionally it would be handy, if some of those options could get overwritten, by the actual CLI args. To unset already set options by CLI args, a new "unset" option becomes necessary. The possibility to override settings from new config file, should be disableable in the config file itself.

To make it more transparent and reliable, Editor Config CLI should provide a Configuration class, utilized by internals and by the outsourced configuration file.

When having more than 500 files and the -n option is not given, a run in a CI pipeline will not cause an error, because code 0 is being returned then.

This behavior should change to return an error code (1 or 2) in order to let the build fail, because no checks are performed then.

The validate method of any rule can return true or false. But this value is not taking into account. Instead, the isValid() method is being checked, which returns true when no error has been added during scan.

To reduce confusion and increase code quality the validate method of rules should not return any value anymore.