And what are they? Neon to Yaml, semi-static to Services, customizable caching, even simpler skipper, short bin and more.
Docker users will be happy for this feature, since it makes ECS much more usable. To enjoy speed of caching of changed files on second run, just tune your config.
# easy-coding-standard.yml parameters: # defaults to sys_get_temp_dir() . '/_easy_coding_standard' cache_directory: .ecs_cache
Thank you Marcin Michalski for adding this feature.
One of the features I really like is skipping particular spots. PHP CS Fixer and PHP_CodeSniffer can ignore whole directory, 1 sniff everywhere or force to put annotation to your code and that's not the way to go. Your code should have no idea about tools you use to analyze it.
What you really need? Exclude 1 file but only for 1 checker. Or 1 checker for group of files and sometimes only 1 code from sniff on 1 file. That all is possible now.
Because details matters and it's pointless to think about code or class, you can now remove
skip_codes key from your config and use
skip section only:
# easy-coding-standard.yml parameters: skip: PHP_CodeSniffer\Standards\Generic\Sniffs\Files\LineLengthSniff: - 'packages/CodingStandard/src/Fixer/ClassNotation/LastPropertyAndFirstMethodSeparationFixer.php' - skip_codes: SlevomatCodingStandard\Sniffs\TypeHints\TypeHintDeclarationSniff.UselessDocComment: - '*packages*'
No need to think, where to put it anymore.
One last detail. Did you use this bin file to run ECS?
vendor/bin/easy-coding-standard # or vendor/bin/easy-coding-standard.php
I know it's pain, mainly during live demo presentations with all that tyops :).
Now this is the only way to use ECS:
Typo proof or at least less error prone. Just change it in you
script section or CI setups and you're ready to go!
Nette\DI a long time ago and with it its markup language - Neon. Then it moved to
Symfony\DependencyInjection in Symplify 2.0, because it was just impossible to reject all these awesome Symfony 3.3 features by Nicolas Grekas. But this was just partial migration - Neon files still worked.
That lead to situation, where 5 custom-cool-classes simulated loading transforming Neon to Yaml format, merging it and then passing to Symfony Container, hoping all went well. And it worked. Well, most of the times.
Based on feedback from community around Symplify, rejection of ECS in Doctrine\CodingStandard where Neon was one of reasons and weird feeling from promoting "local-only standard", I decided to move to Symfony completely.
I had one problem - missed services autocomplete in Yaml files. But you know what they say:
There are no solutions. There are only trade-offs
I hear you community, so lets trade! From ECS 4, you can use Yaml everywhere with syntax you know, behavior from Symfony ecosystem you know and with no need to learn new standard.
Well just rename
then read about it in Neon vs. Yaml and How to Migrate Between Them.
Thanks to Yaml, we could use finally use full power of Symfony\DependencyInjection component, constructor injection, autowiring... again, all that you probably already know from Symfony.
Why? ECS is basically a Symfony application with DI Container. It loads all checkers from config you provide, turns them into services and then uses those services to check the code.
Could you tell that from?
# easy-coding-standard.yml checkers: ArrayFixer: ~
I could not. I recall how frustrated I was, when I digged through PHP_CodeSniffer and PHP CS Fixer years ago and find out that Sniffs and Fixers are only statically registered services, nothing more.
Why not make such intent explicit?
# easy-coding-standard.yml services: ArrayFixer: ~
Yaml was the only missing part to do this. And ECS has it now, so does the explicit services! And you can do and use any feature you Symfony know. Magic no more #metoo.
# easy-coding-standard.yml - checkers: + services: Symplify\CodingStandard\Fixer\Import\ImportNamespacedNameFixer: include_doc_blocks: true - - SlamCsFixer\FinalInternalClassFixer: + SlamCsFixer\FinalInternalClassFixer: ~
Yeah, trade-offs bla bla bla... but what is ECS without class autocomplete? That is killer feature compared to other 2 tools that use strings for Fixer and Sniff names that you have to remember.
I created issue at Symfony Plugin and hyped people all over the planet to up-vote it. I even seriously though about going to PHPStorm Plugin workshop and learn Java only to add this feature it. Should I try or should I let it go?
But one night, after glass of wine trying to achieve Ballmer Peak, I accidentally made a typo in
And that glass of wine, my friends, was hell of a trade-off!
Do you want more on this topic? You might like these related posts: New in Symplify 3: 4 Improvements in EasyCodingStandard