1. Home
  2. Blog
  3. New in Symfony 3.2: YAML deprecations

New in Symfony 3.2: YAML deprecations

September 6, 2016 Avatar of Javier Eguiluz Javier Eguiluz

Symfony 3.2 will introduce some minor YAML deprecations in order to make the Yaml component fully compliant with the YAML specification.

Deprecated missing spaces after map keys

Contributed by
Christian Flothmann
in #19504.

When defining a map, YAML requires to add at least one white space after the colon that separates the key and the value. In previous Symfony versions we didn't require to include that white space. In Symfony 3.2 we've deprecated this behavior and Symfony 4.0 will throw a ParseException.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# It works in Symfony 3.1, it's deprecated in 3.2, it fails in 4.0
parameters:
    foo:bar
    published:true
    default_page:1

# It works in every past, present and future Symfony version
parameters:
    foo: bar
    published: true
    default_page: 1

Deprecated defining duplicated keys

Contributed by
Alex Pott
in #19529.

In previous Symfony versions, when a single YAML file contained duplicated keys the first key was used and the rest were silently ignored:

1
2
3
4
5
6
# the second key is ignored and this document is parsed
# as: 'parameters' => array('key' => 'aaa')
parameters:
    key: 'aaa'
    # ...
    key: 'bbb'

In Symfony 3.2 this behavior is deprecated and Symfony 4.0 will throw a ParseException, so it's time to check if your YAML files contain duplicated keys.

Moved the yaml:lint command to the Yaml component

Contributed by
Robin Chalas
in #19139.

Not strictly a deprecation, but in Symfony 3.2 we decided to move the yaml:lint command from the FrameworkBundle to the Yaml component. This will allow you to lint your YAML files without having to require the entire FrameworkBundle.

The only difference is that when using yaml:lint via the component you can check files and directories, whereas using it in the full-stack framework also lets you check entire bundles:

1
2
3
4
5
6
# it works in the component and the framework
$ ./bin/console yaml:lint parameters.yml
$ ./bin/console yaml:lint app/config/

# it only works in the framework
$ ./bin/console yaml:lint @AppBundle

Comments

Tomáš Votruba said on Sep 6, 2016 #1

I really like those simplifications. Decreasing complexity leads to better understandability.
Wat to go!

complex said on Sep 6, 2016 #2

will yaml:lint warn about the new deprecations?

Javier Eguiluz said on Sep 6, 2016 #3

@complex yes, because the yaml:lint command uses the parse() method of the Yaml parser to check if there are any errors ... and the parser will throw these deprecations.

Guilhem Niot said on Sep 6, 2016 #4

Not having spaces after keys should be allowed and be considered as a value according to the spec, not throw an exception:
it is not in the forbidden indicator (http://www.yaml.org/spec/1.2/spec.html#c-flow-indicator) and it is explicitly allowed in values (http://www.yaml.org/spec/1.2/spec.html#ns-plain-char(c)).

Teoh Han Hui said on Sep 7, 2016 #5

@Ener-Getick

It's more nuanced than that: http://www.yaml.org/spec/1.2/spec.html#: mapping value//

Guilhem Niot said on Sep 7, 2016 #6

@Teoh Han Hui your link goes in the same direction, {foo:bar} should be parsed as {"foo:bar"} but still be valid ;)

Teoh Han Hui said on Sep 13, 2016 #7

@Ener-Getick If you look at the above example (http://symfony.com/blog/new-in-symfony-3-2-yaml-deprecations#deprecated-missing-spaces-after-map-keys), it is indeed invalid and should throw an exception.

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.