Upload settings_schema.json before validator-consumer assets

[NathanPJF]

WHY are these changes introduced?

Closes shop/issues-merchant-workflows#1929

This is the CLI counterpart to the new color_palette setting type. The color_palette is declared at the theme level (config/settings_schema.json). Blocks and sections set their own color default value via {{ settings.<palette>.<role> }}.

Issue: The shopify theme push fails on the first push to a fresh dev theme whenever a block/section uses that pattern. The second push to the same theme succeeds, because by then config/settings_schema.json has been uploaded and the server-side validator that runs on the block file can resolve the reference against the stored palette.

Example of first push errors:

"Invalid schema: setting with id=<value> default must be a color or dynamic source access path"

The second push to the same theme succeeds, because by then the user's config/settings_schema.json has been uploaded and the server-side validators can resolve the reference.

Root cause. The CLI uploads files in dependency order. Today config/settings_schema.json is bundled with config/settings_data.json into a single configFiles bucket and uploaded last — after every block/section/section-group/template asset. When the server-side validator on a block file checks a {{ settings.<palette>.<role> }} default, it queries the theme's currently-stored settings_schema.json, which on a fresh theme is the '[]' placeholder seeded by ensureThemeCreation. The reference can't resolve until the user's real schema lands.

WHAT is this pull request doing?

Splits the configFiles partition bucket into configSchemaFile and configDataFile, then reorders the dependentFiles upload chain:

• Before: layout → blocks → sections.liquid → sections.json → templates.json → contextualized → config (schema + data together, last)
• After: config schema → layout → blocks → sections.liquid → sections.json → templates.json → contextualized → config data

settings_schema.json is purely declarative and has no upstream dependencies, so it's safe to upload first. settings_data.json legitimately needs to be last — its current and presets validate against the freshly-uploaded schema and can reference sections / templates uploaded earlier. The matching orderFilesToBeDeleted is updated to delete data before schema (the inverse of the new upload order).

Files changed (all in packages/theme/src/cli/utilities/):

• theme-fs.ts — split configRegex into configSchemaRegex / configDataRegex; split partitionThemeFiles bucket.
• theme-uploader.ts — reorder dependentFiles (schema head, data tail), invert orderFilesToBeDeleted, expand the header comment explaining the contract. Exports orderFilesToBeUploaded and ChecksumWithSize so the new test can exercise the function directly.
• theme-fs.test.ts — partition tests updated for the two new buckets.
• theme-uploader.test.ts — existing upload-order test updated for the new sequence; new direct unit test of orderFilesToBeUploaded asserts schema-first / data-last and that every validator-consumer asset (blocks, section liquid, section group JSON, template JSON, contextualized template JSON) is sequenced between them.

Verified scope. Block-level color_palette dynamic-source defaults — Horizon's input_border_color repro succeeds on first push. The same upload-order fix is expected to cover the section-group and template JSON datasource walkers (same dependency on the stored schema), though those weren't independently end-to-end verified.

Out of scope. Validator paths that don't consult the stored settings_schema.json at all — for example, the string_or_datasource validator that runs on URL / link block settings — fail before any schema lookup and aren't affected by reordering. Those need a separate server-side change.

How to test your changes?

Test a color_palette type input on a store with the new feature enabled.

1. Create blocks/test.liquid

{% schema %}
{
  "name": "Test",
  "settings": [
    { "type": "color", "id": "link_color", "label": "Link Color", "default": "{{ settings.color.link_color }}" }
  ]
}
{% endschema %}

2. Updated config/settings_schema.json with this setting.

      {
        "type": "color_palette",
        "id": "color",
        "default": {
          "background": "#ffffff",
          "link_color": "#000000"
        }
      },

3. Run pnpm shopify theme push --path=<YOUR_PATH> and verify no error messages

Post-release steps

None.

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows) — pure JS, no platform-specific code paths touched.
• I've considered possible documentation changes — none needed; user-facing behavior is "first push now works," no new flags or commands.
• I've considered analytics changes to measure impact — none needed.
• The change is user-facing — patch bump for @shopify/theme, changeset added (.changeset/fix-theme-push-fresh-dynamic-source-defaults.md).

[graygilmore]

I think this makes sense. Spinning up a chat in Slack to talk about some historical bits.

[graygilmore]

I have no idea what this test is doing. Is there another way we could show this?

[NathanPJF]

I removed it. I had it originally to validate the order of files uploaded, but the existing test this PR updates already did that. I wanted to have an extra test enforcing the order since it's crucial, but when I wrote a 'simpler' one, I realized it wasn't adding additional value.

[dmerand]

Does this ordering matter at runtime for deletion as well? Currently it looks like deletion happens in async batches where the ordering might not be guaranteed.

[NathanPJF]

Effectively it doesn't. My understanding is that mirrors the upload just for consistency, but not an actual contract. So I'll update my inline comment about "config file consideration" just to not make it seem important

But as to whether it actually matters: the utility of deleting is getting the remote theme in sync with local dev. Doesn't matter where settings_schema is because there's no use-case for ever deleting that file and keeping a functioning theme.

[dmerand]

If schema upload fails, would you want later dependent uploads to proceed? Current batch upload doesn't throw when bulk upload fails.

[NathanPJF]

This is a great point, but I don't want to tackle that in this PR because its a larger change to the failure mode of theme push. Today theme uploads behave as "upload as much as possible" and we get reports of what couldn't be uploaded. Adding a dependency check sounds useful, it's a "fail fast" approach - something that we could be benefitting from already given the dependencies for Layout files > JSON templates, Liquid sections > JSON sections, etc. But I'm hesitant to change it just yet as I'm no sure how devs may be benefitting from the current "upload as much as possible" mechanic.