Validation issues with block.json in a few core blocks

[mkaz]

What problem does this address?

When adding the schema definition to core blocks in #35900 it highlighted the following validation errors in a few core blocks.

I'm not sure if the issues are with the schema definition or invalid properties in the block.json each will need to be investigated, adding this ticket so they are not lost.

• Button block - spacing - padding - horizontal - invalid value
• Column block: templateLock - type missing
• Cover block: templateLock - type missing
• File block: viewScript - invalid property
• Group block: templateLock - type missing
• Navigation block: viewScript - invalid property
• Post-Comment-content block - spacing - padding - horizontal - invalid value
• Post-comments-form block - style - invalid type

[gziolo]

It looks like changes proposed in #35900 helped to find valid issues. I can confirm that templateLock is missing a type. @oandregal, can you help validate the reported violation for the Global Styles related support?

viewScript is a new property waiting to be included in WordPress 5.9 and it still needs to be documented. The work on it is being tracked in #33542. We need to include it in the block schema. It is documented in the REST API endpoint for the block type:
https://github.com/WordPress/wordpress-develop/blob/2238c302f9598b6f8f4ab0c27b175fd9ca7370fd/src/wp-includes/rest-api/endpoints/class-wp-rest-block-types-controller.php#L529-L535
also in the WP_Block_Type class:
https://github.com/WordPress/wordpress-develop/blob/2238c302f9598b6f8f4ab0c27b175fd9ca7370fd/src/wp-includes/class-wp-block-type.php#L174-L180

Let me also highlight again my question from #35843 (comment):

Out of curiosity, how much work it would be to keep the schema in Gutenberg repository, possibly inside @wordpress/blocks package (or we could create another one with schemas to include also theme.json) and sync it somehow to another place that we could use instead?

I love the idea of having a schema that could be used for validation and I'd be in favor of tighter integration into the existing tooling. One immediate idea for a follow-up for this PR would be to run block.json validation on scaffolded test block on CI as part of:

https://github.com/WordPress/gutenberg/blob/trunk/bin/test-create-block.sh

Now, that we plan to add schema to all core blocks, we could also create an integration test that would validate all block.json files against the schema.

[gziolo]

@ryanwelcher, this could be also useful to add the block.json schema to the blocks present in https://github.com/WordPress/gutenberg-examples.

[ryanwelcher]

@ryanwelcher, this could be also useful to add the block.json schema to the blocks present in https://github.com/WordPress/gutenberg-examples

The schema property was added with WordPress/gutenberg-examples#167 - thanks @mkaz !

[mkaz]

@gziolo I like the idea of having it internal to Gutenberg repo.
What do you recommend a "@wordpress/schemas" package?

We would also want to include the theme.json schema. We can mirror any changes to the SchemaStore URL so any old URLs would still work, plus get better exposure if people look there first,. But the master version would live in Gutenberg repo.

Also, in Gutenberg it would get automatic versioning with the tags/branches of each release,
Using a URL like one could validate against whatever version they were targeting:
https://github.com/WordPress/gutenberg/tree/wp/5.8/packages/schemas/block.json

[gziolo]

@gziolo I like the idea of having it internal to Gutenberg repo. What do you recommend a "@wordpress/schemas" package?

That's one of the options that could help with maintenance. There are also i18n related config files for block.json and theme.json that we could move there:
https://github.com/WordPress/gutenberg/blob/trunk/packages/blocks/src/api/i18n-block.json
https://github.com/WordPress/gutenberg/blob/trunk/lib/theme-i18n.json

Unless @mkaz or @ajlende know how to annotate the translatable fields directly in the schema definition 😄

[ajlende]

We could add custom fields to the schema file to indicate if the field is translatable or not. Some of the schemas in SchemaStore use a custom markdownDescription field (used by VS Code) that isn't part of the schema spec, so I'd expect that most validators would just ignore invalid values rather than halting.

[oandregal]

Button block - spacing - padding - horizontal - invalid value

Checked this one, which was added at #33859 and it appears that horizontal & vertical are proper values. Checked the PR to schemastore and those values are also there. Unfamiliar with the schemastore syntax but probably we'd need to update the schema to allow the existing values (see comment).

[oandregal]

Post-Comment-content block - spacing - padding - horizontal - invalid value

Same as button above.

[ajlende]

• Button block - spacing - padding - horizontal - invalid value
• Post-Comment-content block - spacing - padding - horizontal - invalid value

Fix in SchemaStore/schemastore#1903

[ryanwelcher]

I've also got a PR to address some items being moved into typopgraphy - SchemaStore/schemastore#1898