-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Yaml] Allow linter to detect legacy boolean literals #30137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I am not too much in favour of adding this. The parser already is quite complex and that won't become better if we start to also try to detect syntax elements that were interpreted differently in YAML 1.1 (the handling of unquoted yes/no/on/off isn't the only difference). I would rather search for a dedicated tool that you could use in your CI to detect these things. |
I'm using |
We already do handle the affected boolean literals differently in the dumper, though.
I wouldn't aim for completeness. The boolean literals change is from my point of view the most significant one, especially with regards to how php's implicit type casts work: For instance,
Well, a dedicated tool for this task would be a YAML linter. The YAML component contains such a linter. And so far, it does a great job. I'd really appreciate it if I would not need to add another linter just for this small issue. |
the thing is, the literal
The linter command is simply using the parser and reporting any syntax error. Nothing else. |
Right, that's the problem.
Yes, see my description above. I would like to add a flag that makes the parsing stricter than the standard, disallowing those old literals. That would be a safety feature that can be enabled when interacting with systems that still operate on YAML 1.1, similar to what has been done in #13209 and #13262. The lint command would then receive an option to allow the user to enable the flag. |
Not in favor of this. You already have yamllint as suggested. |
For all reasons discussed here, I think we can close as won't fix. |
this would not make parsing stricter. It would making parsing non-compliant with the spec, as it would make
These PRs were about choosing the way we dump YAML, by selecting the representation which is safer to use by taking these parsers into account. That's entirely different, as it does not make us non-compliant. The thing is, a linter enforcing extra rules than the syntax cannot be implemented on top of a parser turning the Yaml into PHP values directly (as our parser does), as that removes lots of information about the way things were represented in YAML. You would need something building an AST of the YAML, to be able to distinguish a |
Description
I'm currently migrating a legacy project to Symfony 4. The old application is built quite a lot around YAML configuration files, written according to the YAML 1.1 specification.
One of the main differences to the YAML 1.2 specification that Symfony 2/3/4 implements is that unquoted literals
on
,off
,yes
andno
are parsed as boolean values while YAML 1.2 only allowstrue
andfalse
.For example, the Symfony 1.2 documentation advertises the usage of the alternative boolean literals:
The nasty part is that a YAML 1.2 parser would not fail on those literals, but instead parse them as strings. Of course, we need to fix our YAML files, but I'd like to make sure we don't introduce any regressions. This is why I'd like Symfony's YAML linter command to report the usage of those literals. It shouldn't do so by default, but I'd like to be able to configure the command accordingly.
Possible Solution
I've looked into this already and the best idea I could come up with is introducing a flag that makes the
Symfony\Component\Yaml\Inline
class throw aParseException
if one of the legacy literals is encountered unquoted. That flag could be leveraged by introducing an option (e.g.--fail-on-legacy-bool
) to theLintCommand
.Should I submit a PR?
The text was updated successfully, but these errors were encountered: