8000 [Yaml] Allow linter to detect legacy boolean literals · Issue #30137 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[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

Closed
derrabus opened this issue Feb 11, 2019 · 8 comments
Closed

[Yaml] Allow linter to detect legacy boolean literals #30137

derrabus opened this issue Feb 11, 2019 · 8 comments

Comments

@derrabus
Copy link
Member

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 and no are parsed as boolean values while YAML 1.2 only allows true and false.

For example, the Symfony 1.2 documentation advertises the usage of the alternative boolean literals:

default:
  is_secure: off

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 a ParseException 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 the LintCommand.

Should I submit a PR?

@xabbuh
Copy link
Member
xabbuh commented Feb 15, 2019

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.

@ro0NL
Copy link
Contributor 8000
ro0NL commented Feb 15, 2019

I'm using yamllint to lint all YAML stuff in my app. It has a nice truthy rule which IIUC solves this: https://yamllint.readthedocs.io/en/stable/rules.html#module-yamllint.rules.truthy

@derrabus
Copy link
Member Author

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

We already do handle the affected boolean literals differently in the dumper, though.

(the handling of unquoted yes/no/on/off isn't the only difference).

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, off would evaluate to false when parsed with YAML 1.1 rules mode and to "off" when parsed with YAML 1.2 rules. And (bool) "off" === true.

I would rather search for a dedicated tool that you could use in your CI to detect these things.

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.

@stof
Copy link
Member
stof commented Feb 18, 2019

the thing is, the literal off is not a syntax error at all. In YAML 1.2, it is a string literal.

The YAML component contains such a linter.

The linter command is simply using the parser and reporting any syntax error. Nothing else.
What you are asking here is a linter enforcing extra rules than the syntax (similar to what eslint does for JS for instance). And the YAML component does not provide such a tool (which cannot be built on top of our parser).

@derrabus derrabus changed the title [Yaml] Allow linter to detect legacy boolen literals [Yaml] Allow linter to detect legacy boolean literals Feb 18, 2019
@derrabus
Copy link
Member Author

the thing is, the literal off is not a syntax error at all. In YAML 1.2, it is a string literal.

Right, that's the problem.

What you are asking here is a linter enforcing extra rules than the syntax

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.

@ostrolucky
Copy link
Contributor

Not in favor of this. You already have yamllint as suggested.

@fabpot
Copy link
Member
fabpot commented Feb 21, 2019

For all reasons discussed here, I think we can close as won't fix.

@fabpot fabpot closed this as completed Feb 21, 2019
@stof
Copy link
Member
stof commented Feb 21, 2019

I would like to add a flag that makes the parsing stricter than the standard, disallowing those old literals.

this would not make parsing stricter. It would making parsing non-compliant with the spec, as it would make off an invalid value, while it is valid in Yaml.

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.

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 on literal from a on quoted literal. And that would require a full rewrite of the component.

63CB

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants
0