Update mutation variables for AppVersionCreate

[dmerand]

WHY are these changes introduced?

Following up to #5436 per this issue. Per these issues, we've updated the API shape on the back-end and need to update the CLI to match.

WHAT is this pull request doing?

This changes the CreateAppVersion GraphQL call to use the updated AppVersionInput data shape. I've also added an AppVersionSourceWithUrl interface to help to ensure that we're conforming to the API locally. See the previous PR for a brief discussion of that.

We also didn't have any tests for the deploy command, so I've added some.

How to test your changes?

• p shopify app init
• p shopify app deploy - which will exercise the non-source-url branch
• p shopify app generate extension and pick e.g. Admin Action or another extension that uses assets.
• p shopify app deploy - which will exercise the source-url branch

Post-release steps

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
• Existing analytics will cater for this addition
• PR includes analytics changes to measure impact

Checklist

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

[github-actions]

Coverage report

St.❔	Category	Percentage	Covered / Total
🟡	Statements	75.84% (+0.13% 🔼)	9124/12031
🟡	Branches	71.06% (+0.15% 🔼)	4463/6281
🟡	Functions	75.52% (+0.13% 🔼)	2379/3150
🟡	Lines	76.36% (+0.11% 🔼)	8614/11281

Test suite run success

2069 tests passing in 923 suites.

Report generated by 🧪jest coverage report action from 8d20719

[dmerand]

I pulled name as well, on the theory that we're either going to pull name from the branding module (short-term), or update the manifest format to include it longer-term.

[github-actions]

We detected some changes at packages/*/src and there are no updates in the .changeset.
If the changes are user-facing, run "pnpm changeset add" to track your changes and include them in the next release CHANGELOG.

[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

packages/cli-kit/dist/private/node/session/identity-token-validation.d.ts

export declare function validateIdentityToken(token: string): Promise<boolean>;

Existing type declarations

packages/cli-kit/dist/private/node/conf-store.d.ts

@@ -3,14 +3,16 @@ interface CacheValue<T> {
     value: T;
     timestamp: number;
 }
+export type IntrospectionUrlKey = ;
 export type PackageVersionKey = ;
 export type NotificationsKey = ;
 export type NotificationKey = ;
 export type GraphQLRequestKey = ;
 type MostRecentOccurrenceKey = ;
 type RateLimitKey = ;
-type ExportedKey = PackageVersionKey | NotificationsKey | NotificationKey | GraphQLRequestKey;
+type ExportedKey = IntrospectionUrlKey | PackageVersionKey | NotificationsKey | NotificationKey | GraphQLRequestKey;
 interface Cache {
+    [introspectionUrlKey: IntrospectionUrlKey]: CacheValue<string>;
     [packageVersionKey: PackageVersionKey]: CacheValue<string>;
     [notifications: NotificationsKey]: CacheValue<string>;
     [notification: NotificationKey]: CacheValue<string>;
@@ -57,13 +59,12 @@ export declare function cacheStore(key: ExportedKey, value: string, config?: Loc
  */
 export declare function cacheRetrieve(key: ExportedKey, config?: LocalStorage<ConfSchema>): CacheValue<string> | undefined;
 export declare function cacheClear(config?: LocalStorage<ConfSchema>): void;
-export interface TimeInterval {
+interface TimeInterval {
     days?: number;
     hours?: number;
     minutes?: number;
     seconds?: number;
 }
-export declare function timeIntervalToMilliseconds({ days, hours, minutes, seconds }: TimeInterval): number;
 /**
  * Execute a task only if the most recent occurrence of the task is older than the specified timeout.
  * @param key - The key to use for the cache.

packages/cli-kit/dist/public/node/api/graphql.d.ts

@@ -1,4 +1,4 @@
-import { ConfSchema, TimeInterval } from '../../../private/node/conf-store.js';
+import { ConfSchema } from '../../../private/node/conf-store.js';
 import { LocalStorage } from '../local-storage.js';
 import { rawRequest, RequestDocument, Variables } from 'graphql-request';
 import { TypedDocumentNode } from '@graphql-typed-document-node/core';
@@ -12,10 +12,11 @@ export interface GraphQLVariables {
 }
 export type GraphQLResponse<T> = Awaited<ReturnType<typeof rawRequest<T>>>;
 export interface CacheOptions {
-    cacheTTL: TimeInterval;
+    cacheTTL: CacheTTL;
     cacheExtraKey?: string;
     cacheStore?: LocalStorage<ConfSchema>;
 }
+export type CacheTTL = number;
 interface GraphQLRequestBaseOptions<TResult> {
     api: string;
     url: string;

[MitchDickinson]

LGTM, just one small nit/suggestion that isn't really related to your PR directly anyway.

[MitchDickinson]

Not really your PR but since the function argument usage is so different between both versions of this request, I wonder if it'd be better to have two functions: i.e. deploy() and deployWithUrl() or something. I suspect it'd be easier to work with the interface if this was the case, instead of having to worry about a bunch optional function args

[dmerand]

I like the idea. Some observations:

• To do so would involve restructuring a couple of nested interfaces: AppDeployOptions which contains AppDeployVariables where bundleUrl is optional.
• This interface is shared across AppManagementClient and PartnersClient -- and PartnersClient is where this AppDeployVariables data shape comes from originally.

So while we could refactor it now, I'm wondering if it would simplify things given the two platform clients would not potentially have diverging interfaces. Perhaps easier to do post partners migration?