Reject empty or whitespace-only configKey values in include_assets builds

[JoshuaWhite1]

WHY are these changes introduced?

Splitting out the empty/whitespace validation from #7504.
The additional path validation from that PR requires a larger conversation, while this portion is a lot simpler.

WHAT is this pull request doing?

Adds an empty-value validation pass in copyConfigKeyEntry that throws AbortError with message '<field>' can't be empty. when a configKey resolves to an empty or whitespace-only string.

• Validation runs before any filesystem I/O — no partial copies on failure
• Error message uses the leaf segment of the configKey ('assets', not 'extension_points[].assets'), matching what the developer wrote in their TOML
• Field omitted entirely still works — the check only triggers when a value is explicitly written as empty. Optional fields still allowed.
• Applies to every configKey routed through this helper: assets, tools, instructions, and intents[].schema (on extension_points[] and targeting[])

How to test your changes?

Follow the steps in #7504

• test deploying an app with assets = "./assets". assert correct value does not error
• test deploying an app with assets = "" assert "cannot be empty" error is thrown
• test deploying an app with assets = " " assert cannot be empty error is thrown

Post-release steps

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes
• I've considered analytics changes to measure impact
• The change is user-facing — I've identified the correct bump type (patch for bug fixes · minor for new features · major for breaking changes) and added a changeset with pnpm changeset add

[JoshuaWhite1]

• Reject empty or whitespace-only configKey values in include_assets builds #7530 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

⚠️ Potential Breaking Changes Detected

This PR contains changes that may break the existing contract.

@shopify/dev_experience — this PR contains breaking changes that require coordination for the next major release. This check will remain failed until a member of the team approves the workflow run.

💬 Head to #help-dev-platform to discuss timing and plan the release.

📦 Major Version Changesets

The following changesets request a major version bump:

Changeset	Package
thin-webs-notice.md	'@shopify/plugin-did-you-mean': major
thin-webs-notice.md	'@shopify/plugin-cloudflare': major
thin-webs-notice.md	'@shopify/create-app': major
thin-webs-notice.md	'@shopify/cli-kit': major
thin-webs-notice.md	'@shopify/store': major
thin-webs-notice.md	'@shopify/theme': major
thin-webs-notice.md	'@shopify/app': major
thin-webs-notice.md	'@shopify/cli': major
thin-webs-notice.md	'@shopify/e2e': major

[Copilot]

Pull request overview

This PR adds an early validation guard to the copyConfigKeyEntry helper used by the include-assets build step to reject configKey values that are explicitly set to an empty or whitespace-only string, failing fast before any filesystem copying begins.

Changes:

• Add a pre-I/O validation pass that throws an AbortError when a resolved config path is empty/whitespace-only.
• Format the error message using the leaf field name (e.g., assets) rather than the full dotted configKey path.
• Add unit tests covering empty string, whitespace-only string, and nested configKey behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
packages/app/src/cli/services/build/steps/include-assets/copy-config-key-entry.ts	Adds early validation to reject empty/whitespace-only resolved config paths and throw an AbortError with a leaf-field message.
packages/app/src/cli/services/build/steps/include-assets/copy-config-key-entry.test.ts	Adds tests verifying the new guard triggers for empty/whitespace-only values and uses the leaf field name for nested keys.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[melissaluu]

We should do the check earlier when we get the value so we don't have to do the extra unnecessary work of setting up the paths etc.

[melissaluu]

To keep things simple, let's just add the check here to scope this validation to the single string value block - this will fulfill our current use case.

In the case where an asset key can have an array, I think we should review what the expected outcome should be for arrays before forcing an error if only one of the paths are empty string - and it's out of scope for us ATM so we can defer