Is lint:yaml about warnings or only errors ? Because if it is only errors, I am not sure we will catch anything with such a check…

If it show deprecations it could be worth it though… for instance, not quoting service ids has been deprecated lately.

The command twig:lint was decoupled from the framework in #9855. It must be as easy for yaml:lint.
I see only 1 line that depends on the FrameworkBundle.

yeah, and this is only about supporting things like @FooBundle/...

The last question is : in which component this generic command should be placed ? Currently, it depends on Console, Yaml and Finder.

IMO, the Yaml component is the best candidate to host this command because that's a feature of Yaml.

IMO, the Yaml component is the best candidate to host this command because that's a feature of Yaml.

Agree. And what about having a binary?

I would vote for the Yaml component as well.

Is it convenient to introduce a class in the Yaml component that depends on the Console+Finder ones?
It wasn't a problem for the TwigLintCommand as twig has it's own bridge suggesting a large set of components.

I personally made a private port of the YamlLintcommand as a single-command app (yaml-lint binary) based on the 3 required components so I'm 👍 for having this, but maybe outside of the symfony components. Maybe open a small binary based library like the php-cs-fixer, as suggested by @soullivaneuh.

the finder dependency could be avoided actually, by using SPL iterators directly without the nice API of the Finder (should be easy as the command just does a recursive iteration and then filters files by extension. It does not rely on fancy features of the Finder).

In fact a standalone library providing only a linter sounds overkill.
See #19139 for moving it in the Yaml component.

@chalasr It's a good start, but in this case we still have to create the console file calling this command.

I still think having a ready-to-use package is a good idea. WDYT it's overkill?

@soullivaneuh I quickly changed my mind on that.
I proposed to add it as executable to the yaml component in #19916.
Unfortunately it has been rejected because components aren't meant to provide ready-to-use executables.
Finally, we added the content of the executable in the docs so that anyone can copy-paste it.

But I still think you're right about that having it as a package makes sense. It looks like there is a similar intent for twig btw: twigphp/twig-lint

I agree with @soullivaneuh's proposal. I'd love something simple that I can use in Travis CI and deployment scripts. Thanks!

I was looking into creating a small package for this. But in fact there already is one: https://github.com/certificationy/yaml-linter

@xabbuh I wasn't asking for a separate package/component/bundle/etc. I just need that the component itself provides a ready-to-use linter binary. Something like this:

$ php .../vendor/symfony/.../translation/Resources/bin/lint.php

The "binary" would be a minimal Symfony console app with just 1 command.

@javiereguiluz I prefer the .phar solution, but this could be enough too. 😉

👍 for putting such binaries into the Resources directory of each component

We now provide binaries in components (e.g. #26654), reopening.

Hello @chalasr,

is something like that useful?

https://github.com/certificationy/yaml-linter

How can I help with that?

Mickaël

Another one: https://github.com/asm89/twig-lint

What would be the goal of a separate package? When I recently made an attempt to improve the linting capabilities of the YAML component (#30137), it was rejected because there are already better linters out there.

To me, we only need to provide an executable in the Yaml component.
That executable would create a console application, wire the LintYamlCommand and run it.
The docs shows how to write such binary on your own, so closing here would mean removing that example from the docs and replace it by "just use the lint binary".

Syntax validation is part of the Yaml component features, there is no point in making it a dedicated package as soon as the component provides the code needed to use it.

If this issue is available I would gladly implement this one :) @fabpot @chalasr

The docs shows how to write such binary on your own, so closing here would mean removing that example from the docs and replace it by "just use the lint binary".

Contributing the lint.php file directly into the Yaml component is enough to fix this issue or do you need more?

Yes, nothing more to me. PR welcomed from anyone, could be nice to let @igor-susic doing it for its first contribution.

@chalasr If others agree, I would like to be assigned and deal with this one 😄

@igor-susic Are you still working on this one? I would be happy to provide a PR in case you don't have time.

Another one https://github.com/HeahDude/yaml-linter