Disallow unknown properties on fields definitions

[jsoriano]

What does this PR do?

Disallow unknown properties on fields definitions.

Why is it important?

Avoid typos as the ones reported in elastic/integrations#2643.

Checklist

• I have added test packages to test/packages that prove my change is effective.
• I have added an entry in versions/N/changelog.yml.

Related issues

• Related to fields yaml files typos integrations#2643.

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-02-21T12:02:41.647+0000

• Duration: 3 min 15 sec

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[mtojek]

I like this idea in general, but I remember we kept it open because we couldn't satisfy all features (multi-fields, example, etc.). Did you check how does this change behaves with existing packages?

[jsoriano]

Did you check how does this change behaves with existing packages?

I have checked with some packages now, and I have found that most of the missing properties can be added to the spec.
The only exception would be examples, for that we would need some kind of type: any, or we should change all of them to their string representation.

To add a type, we would need further customization options in the jsonschema library we use. A limitation I have also found in #278.

Changing the examples to their string representation would be an effort in some packages, but wouldn't be a bad idea, these examples are thought for documentation purposes, and it may be good to have control on their format. We actually use strings for everything, except for numbers, so probably the migration effort could be automated.

In any case we could add a semantic validator to check that the examples comply with the field type.

[jsoriano]

I have created #282 to follow on this.

[jsoriano]

The only exception would be examples, for that we would need some kind of type: any, or we should change all of them to their string representation.

If we change all of them to the string representation, we also need to change the ones imported from ECS, there the examples can contain at least numbers.

[mtojek]

I'm wondering if there aren't any problems with multi fields (see elastic/elastic-package#678).

[jsoriano]

I'm wondering if there aren't any problems with multi fields (see elastic/elastic-package#678).

We can validate them (see ee17cfa), this other issue seems to be about importing external fields with multi fields.

[jsoriano]

Closing this, after #314 we are in a better situation.