Add appLogs to DeveloperPlatformClient interface

[mssalemi]

Part of: https://github.com/Shopify/shopify-functions/issues/605

WHY are these changes introduced?

This PR adds appLogs to the DeveloperPlatformClient interface. Currently this is not necessarily needed since when we poll for app logs, we only have one client currently in use. But to integrate app logs streaming with the developer dashboard, this will make calling the correct request (partners vs app management) simpler.

The next step is this follow Up PR: #5498

WHAT is this pull request doing?

This change enables app logs to be fetched from both the PartnersClient and we will update the methods for the AppManagementClient in a separate PR, providing a consistent interface regardless of which backend is being used.

• Moving app logs fetching from direct HTTP calls to using developerPlatformClient
• Removes direct usage of shopifyFetch in favor of developerPlatformClient.appLogs
• Adds appLogs method to the DeveloperPlatformClient interface
• Implements appLogs in PartnersClient class
• Updates all test files to use testDeveloperPlatformClient instead of mocking shopifyFetch
• Adds new FetchAppLogsOptions interface to type the parameters for app logs fetching
• Updates function signatures to accept developerPlatformClient as a parameter

Component Updates:

• Updates React components and hooks to pass through developerPlatformClient
• Modifies usePollAppLogs hook to use the new client
• Follow Up PR: Integrates subscribe and fetchAppLogs with developer dashboard #5498

How to test your changes?

Test these changes in production using your local CLI on this branch (both commands below should work as expected):

pnpm run shopify app logs --path=./path-to-app

pnpm run shopify app dev --path=./path-to-app

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	76.31% (-0.11% 🔻)	9288/12172
🟡	Branches	71.59% (-0.06% 🔻)	4555/6363
🟡	Functions	75.94% (-0.1% 🔻)	2418/3184
🟡	Lines	76.86% (-0.11% 🔻)	8777/11419

Show files with reduced coverage 🔻

St.❔	File	Statements	Branches	Functions	Lines
🟡	... / utils.ts	75.49% (-11.76% 🔻)	66.67% (-7.84% 🔻)	70.59% (-11.76% 🔻)	74.75% (-12.12% 🔻)
🟢	... / poll-app-logs.ts	94.44% (-5.56% 🔻)	76.47% (-5.88% 🔻)	100%	94.44% (-5.56% 🔻)
🟢	... / app-event-watcher.ts	96.39% (-1.2% 🔻)	88.57% (-2.86% 🔻)	95.45%	100%
🔴	... / app-management-client.ts	35.79% (-0.13% 🔻)	27.66%	34.69% (-0.36% 🔻)	34.8% (-0.14% 🔻)
🔴	... / partners-client.ts	26.95% (-0.19% 🔻)	37.5%	17.24% (-0.3% 🔻)	26.67% (-0.2% 🔻)

Test suite run success

2111 tests passing in 930 suites.

Report generated by 🧪jest coverage report action from 0aa66ff

[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.

[shauns]

Just some light suggestions. Can you put the follow-up PR into a stack with this?

[shauns]

I'm wondering if this should be moved into the partners client. Then you know its always called via the client.

[mssalemi]

Yea, good idea, I think that makes sense give it's used no where else.

[shauns]

I know the existing type of this call is Response, so its not a change, but should it be? Is the response well-typed at all? It looks like within poll-app-logs we strongly expect it to either take an error or success form. In that code we just use as rather than validating what's received. Maybe it'd make sense to have this function (in the client) return AppLogsError | AppLogsSuccess and for it to call .json(). Then callers don't need to think about casting.

That'll leave the function consistent with the rest of the client, as the other methods return data structures not the bare http/graphql responses.

[shauns]

Ok to relax on this if we have a good reason for it to remain as Response.

[mssalemi]

I agree, that makes sense. I refactored this a bit so that we return the actual AppLogsError | AppLogsSuccess. We check the status of the response for the error message and polling time, so I added that to so the return type for error as well since that when we use it. Let me know what you think :)