notify extension dev server of app assets updates

[isaacroldan]

WHY are these changes introduced?

During local development, the extension dev server needs to serve app-level assets (e.g., admin static_root files) and expose app configuration like allowed_domains so the dev console and host can
properly load and refresh them.

WHAT is this pull request doing?

• Serves app assets through a new /extensions/assets/:assetKey/ route on the dev server, with path traversal protection
• Adds allowed_domains and assets (URL + timestamp) to the extensions payload so connected clients know about them
• Bumps asset timestamps and updates allowed_domains in the payload when the admin config changes during dev, triggering a websocket update to clients
• Adds allowed_domains to the admin extension schema and transformRemoteToLocal
• Passes all realExtensions (not just previewable ones) through to the dev server so config-only extensions like admin are visible for extracting app-level config
• Centralizes all admin config extraction in store.ts via a getAdminConfig() helper
• Changes manifest generation to overwrite existing manifest.json instead of throwing
• Watches realExtensions in the file watcher so config extensions with custom watch paths are included
• Adds workaround to always include admin in dev session manifests (incompatible with inheritedUids in Core)

How to test your changes?

1. Create an app with an admin extension that has static_root and allowed_domains configured
2. Run shopify app dev
3. Verify assets are served at the generated asset URLs
4. Modify assets or allowed_domains in the config and confirm the payload updates via websocket

[isaacroldan]

• notify extension dev server of app assets updates #7227 : 2 dependent PRs (#7240 , #7248 ) 👈 (View in Graphite)
• Extract custom watch paths to specifications #7220 : 1 other dependent PR (#7226 )
• Use extension handle to identify extensions in file-watcher #7224
• main

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

[github-actions]

Differences in type declarations

We detected differences in the type declarations generated by Typescript for this branch compared to the baseline ('main' branch). Please, review them to ensure they are backward-compatible. Here are some important things to keep in mind:

• Some seemingly private modules might be re-exported through public modules.
• If the branch is behind main you might see odd diffs, rebase main into this branch.

New type declarations

We found no new type declarations in this PR

Existing type declarations

packages/cli-kit/dist/private/node/ui.d.ts

 import { Logger, LogLevel } from '../../public/node/output.js';
-import React from 'react';
 import { Key, RenderOptions } from 'ink';
 import { EventEmitter } from 'events';
-/**
- * Signal that the current Ink tree is done. Must be called within an
- * InkLifecycleRoot — throws if the provider is missing so lifecycle
- * bugs surface immediately instead of silently hanging.
- */
-export declare function useComplete(): (error?: Error) => void;
-/**
- * Root wrapper for Ink trees. Owns the single `exit()` call site — children
- * signal completion via `useComplete()`, which sets state here. The `useEffect`
- * fires post-render, guaranteeing all batched state updates have been flushed
- * before the tree is torn down.
- */
-export declare function InkLifecycleRoot({ children }: {
-    children: React.ReactNode;
-}): React.JSX.Element;
 interface RenderOnceOptions {
     logLevel?: LogLevel;
     logger?: Logger;
     renderOptions?: RenderOptions;
 }
 export declare function renderOnce(element: JSX.Element, { logLevel, renderOptions }: RenderOnceOptions): string | undefined;
-export declare function render(element: JSX.Element, options?: RenderOptions): Promise<void>;
+export declare function render(element: JSX.Element, options?: RenderOptions): Promise<unknown>;
 export declare class Stdout extends EventEmitter {
     columns: number;
     rows: number;
     readonly frames: string[];
     private _lastFrame?;
     constructor(options: {
         columns?: number;
         rows?: number;
     });
     write: (frame: string) => void;
     lastFrame: () => string | undefined;
 }
 export declare function handleCtrlC(input: string, key: Key, exit?: () => void): void;
 export {};

packages/cli-kit/dist/public/node/ui.d.ts

@@ -34,7 +34,7 @@ export interface RenderConcurrentOptions extends PartialBy<ConcurrentOutputProps
  * 00:00:00 │ frontend │ third frontend message
  *
  */
-export declare function renderConcurrent({ renderOptions, ...props }: RenderConcurrentOptions): Promise<void>;
+export declare function renderConcurrent({ renderOptions, ...props }: RenderConcurrentOptions): Promise<unknown>;
 export type AlertCustomSection = CustomSection;
 export type RenderAlertOptions = Omit<AlertOptions, 'type'>;
 /**

[Copilot]

Pull request overview

This PR extends the local UI extensions development server to support serving app-level assets (notably admin static_root) and to propagate related metadata (URLs + timestamps) through the extensions payload so clients can fetch and refresh those assets during development.

Changes:

• Adds app.allowed_domains and app.assets metadata into the extensions payload and shared type definitions.
• Introduces an HTTP middleware + route (/extensions/assets/:assetKey/...) for serving app assets from configured directories.
• Expands dev file watching and build/include-assets behavior (watch realExtensions; overwrite generated manifest.json; admin spec updates).

Reviewed changes

Copilot reviewed 16 out of 16 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
packages/ui-extensions-server-kit/src/types.ts	Extends App payload types with allowed_domains and assets.
packages/app/src/cli/services/dev/processes/setup-dev-processes.ts	Passes realExtensions into previewable extension process setup.
packages/app/src/cli/services/dev/processes/dev-session/dev-session.ts	Workaround to always include admin in update manifests.
packages/app/src/cli/services/dev/extension/server/middlewares.ts	Adds middleware to serve app assets by key/path.
packages/app/src/cli/services/dev/extension/server.ts	Registers the new app-assets route when asset directories exist.
packages/app/src/cli/services/dev/extension/payload/store.ts	Adds admin-derived app config/assets to payload and tracks asset directories/timestamps.
packages/app/src/cli/services/dev/extension/payload/store.test.ts	Adjusts store option mocks for new constructor usage.
packages/app/src/cli/services/dev/extension/payload/models.ts	Updates payload interface with new app fields.
packages/app/src/cli/services/dev/extension.ts	Triggers admin config/timestamp updates on extension events; refactors server setup call.
packages/app/src/cli/services/dev/extension.test.ts	Updates mocks/assertions for new payload store methods.
packages/app/src/cli/services/dev/app-events/file-watcher.ts	Watches realExtensions files (including config extensions).
packages/app/src/cli/services/build/steps/include-assets/generate-manifest.ts	Changes manifest generation to overwrite existing manifest.json.
packages/app/src/cli/services/build/steps/include-assets-step.test.ts	Updates tests to expect manifest overwrite behavior.
packages/app/src/cli/models/extensions/specifications/admin.ts	Adds allowed_domains to schema; exports AdminConfigType; watches static_root files.
packages/app/src/cli/models/extensions/specification.ts	No functional change (formatting).
packages/app/src/cli/models/extensions/extension-instance.ts	Uses isAppConfigExtension when deciding default dev-session watch behavior.

---

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

[melissaluu]

Can we make this allowedDomains so it's consistent with the other fields which are camel cased?

[alfonso-noriega]

Should we considering passing the extension type as an array of types parameter in case there are in the future other app configs that need extension event?

[isaacroldan]

This a very specific and special case and I don't expect something similar to happen again.
UI Extensions are already handled in a generic way, if at any point appears other extension with custom behavoiur we can see how to generalize it.