ValidSettingsKey: does not validate section settings in template JSON files

[domaine-stijn-slats]

Summary

The existing ValidSettingsKey check validates settings keys inside {% schema %} presets and defaults within Liquid section files. However, it does not validate settings keys in template JSON files (e.g. templates/page.json), where sections are instantiated with their actual store settings.

This means a typo in a setting key in a template JSON goes completely undetected by Theme Check.

Steps to reproduce

1. Create a section sections/main-page.liquid with a schema containing a setting with "id": "heading_tag"
2. In templates/page.json, reference that section with a typo in the settings key:

{
  "sections": {
    "main-page": {
      "type": "main-page",
      "settings": {
        "heading_tagg": "h1"
      }
    }
  },
  "order": ["main-page"]
}

3. Run shopify theme check

Expected behavior

Theme Check reports an error or warning similar to:

Setting 'heading_tagg' does not exist in 'sections/main-page.liquid'.

Actual behavior

No error or warning is reported. The invalid key is silently ignored. The setting has no effect at runtime — which is especially hard to debug during a section schema refactor or key rename.

Context

The existing ValidSettingsKey check operates on SourceCodeType.LiquidHtml and validates settings in the presets and default blocks of a section's own {% schema %}. It does not cover section instances in template JSON files.

A complementary check (or an extension of ValidSettingsKey) would need to:

• Target SourceCodeType.JSON template files
• For each section instance, resolve the corresponding .liquid file
• Parse its {% schema %} and collect valid setting IDs
• Report any key in settings that does not match a valid setting ID

Why this matters

This gap becomes critical in multi-store theme workflows where template JSON files are store-specific and diverge from the main code branch. A renamed setting key in Liquid will silently stop working on any store whose template JSON still references the old key — with no tooling to catch it.

[chippleh1392]

I can take a look at this. I reproduced the current behavior with a focused test: a template JSON section setting can use a key that does not exist in the referenced section schema, and ValidSettingsKey reports no offense.

My read is that the narrow fix is to extend this check onto templates/*.json, resolve each section type to its section schema, and report unknown section setting keys there. I’ll keep it scoped to that path.