You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we allow for custom top level properties in YAML files, custom config keys. Consider the following
# properties.yml
models:
- name: my model
...
soucres:
- name: my_source
...
cats:
- name: Omellete
color: orange
- name: Misu
color: brown
There are two primary issues with the above.
Firstly, it means anytime a new top level property is defined, it is potentially breaking change. This doesn't happen often, but it's still bad. I don't think we're going to add a cats node type, but hey you never know
The bigger problem is that it makes it nearly impossible to detect typos. You may not have noticed in the example YAML above, but I misspelled the "sources" key as "soucres". If you are using the refing the source somewhere you'd likely get an error later on, which is good. However, if you misspell something like models which you use to add data tests, then suddenly your data tests aren't being run (not good).
Solution
Deprecate the custom top level YAML properties. We want to make custom top level YAML properties an error, and at some time it will become an error, but we can't move straight to it being an error. As it being an error would be breaking to projects everywhere, we need to first deprecate it to give people time to fix the problem.
Acceptance criteria
Deprecation warning is fired if a custom top level YAML property is present
A deprecation warning is not fired if a custom top level YAML property is not present
In non-verbose mode a count of the number of occurences is included in the deprecation warning
In verbose mode all the instances are listed in the deprecation warning
Suggested Tests
Deprecation warning is fired if a custom top level YAML property is present
A deprecation warning is not fired if a custom top level YAML property is not present
In non-verbose mode a count of the number of occurences is included in the deprecation warning
In verbose mode all the instances are listed in the deprecation warning
Backport?
N/A
The text was updated successfully, but these errors were encountered:
Problem
Currently, we allow for custom top level properties in
YAML
files, custom config keys. Consider the followingThere are two primary issues with the above.
Firstly, it means anytime a new top level property is defined, it is potentially breaking change. This doesn't happen often, but it's still bad. I don't think we're going to add a
cats
node type, but hey you never knowThe bigger problem is that it makes it nearly impossible to detect typos. You may not have noticed in the example
YAML
above, but I misspelled the "sources" key as "soucres". If you are using the refing the source somewhere you'd likely get an error later on, which is good. However, if you misspell something likemodels
which you use to add data tests, then suddenly your data tests aren't being run (not good).Solution
Deprecate the custom top level
YAML
properties. We want to make custom top levelYAML
properties an error, and at some time it will become an error, but we can't move straight to it being an error. As it being an error would be breaking to projects everywhere, we need to first deprecate it to give people time to fix the problem.Acceptance criteria
Suggested Tests
Backport?
N/A
The text was updated successfully, but these errors were encountered: