Support intents for ui extensions

[vividviolet]

WHY are these changes introduced?

This change modernizes the UI extension asset handling system by replacing the legacy build_manifest approach with a new manifest.json-based system that supports additional asset types including intents.

Related https://github.com/shop/issues-admin-extensibility/issues/2274

WHAT is this pull request doing?

• Adds support for intents field in extension point schemas with type, action, schema, name, and description properties
• Adds Intents to the AssetIdentifier enum for asset handling
• Updates UI extension build pipeline to use include_assets step instead of copy_static_assets, with support for tools, instructions, and intent schemas
• Refactors extension payload generation to read from manifest.json instead of build_manifest, enabling better asset tracking with source file timestamps
• Implements specialized handling for intents assets that transforms them into extension point-level properties with schema asset references
• Updates tests to use the new manifest.json approach and adds comprehensive test coverage for intents, tools, and instructions assets

How to test your changes?

Make sure you have the proper betas applied (see canvas)

1. Create a conditional action extension shopify app generate --template conditional_admin_action
2. Run pnpm shopify app dev and verify the the UI extension has assets (main.js, should_render.js, tools schema url and instructions.md) that are fetchable through the Dev Server. You should be able to preview it in Admin Web
3. Make a change to the action extension's code a verify that live reload works in Admin Web
4. Create an Admin Link intent extension shopify app generate --template admin_intent_link
5. Run pnpm shopify app dev and verify the the Admin link extension has assets (main.js, tools schema url and instructions.md and intents schema URLs) fetchable through the Dev Server
6. Make a change to one of the static files like the intent-schema.json or tools.json and verify that Admin Web receives an update even through the websocket

Measuring impact

How do we know this change was effective? Please choose one:

• n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes

[vividviolet]

• Support assets for admin links app intents #7132
• Support intents for ui extensions #7134 👈 (View in Graphite)
• Add manifest generation to include_assets build step #7016 : 1 other dependent PR (#7017 )
• Refactor extension build process to use modular build steps #6867 : 3 other dependent PRs (#6868 , #6869 , #7027 )
• Add client steps implementation to support existing functionalities #6966 : 1 other dependent PR (#6941 )
• Create abstract client steps infrastracture to externalize the ap modules client configurations #6965
• main

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

[vividviolet]

@isaacroldan this fixes the issue mentioned here. There was a regression where we were getting updates even when the assets fail to build because we were serving them from the .dev-bundle which gets freshly created even when the build fails but it should be using the local assets. When the build fails the old local assets should not be deleted and we should not get a new update event in the websocket

[vividviolet]

Nope, never mind. I double checked and it still sends an update event, something else is going on

[vividviolet]

Previously this was looking at copied files which broke when including assets for the adminspecificaiton after I fixed the issue where files were getting a new name on every build in dev even when there was no collision.

Fixed this to match copy-by-pattern.ts by looking at the source files, not the files in the destination folder.

[vividviolet]

Same here, fixed this to match copy-by-pattern.ts by looking at the source files, not the files in the destination folder.