Store auth restructure

[dmerand]

What

Restructure shopify store auth under packages/cli/src/cli/services/store/auth/ and split the main auth responsibilities into explicit auth-domain seams.

This keeps the command contract the same while making auth ownership easier to review and build on.

Why

The store auth fast-follow landed quickly and left auth responsibilities spread across a few files with blurry ownership.

That made it harder to reason about:

• local session bucket storage
• expiry / refresh / invalidation policy
• auth-related HTTP
• current-user selection semantics

It also made the execute-side follow-up harder to stage cleanly.

The goal here is to make the auth domain legible on its own before building the execute-side cleanup on top.

How

This PR moves auth code under services/store/auth/ and separates:

• auth/index.ts — auth orchestration
• auth/session-store.ts — local session bucket storage and current-user selection
• auth/session-lifecycle.ts — expiry / refresh / invalidation policy
• auth/token-client.ts — auth-related HTTP
• auth/config.ts / auth/recovery.ts — shared auth support code

It also:

• renames the stored-session getter to getCurrentStoredStoreAppSession(...) so current-user semantics are explicit
• updates existing auth consumers to use the new auth seams
• keeps malformed local session state from leaking past the storage boundary

High-level ownership after this PR:

command -> auth/index.ts -> session-store / session-lifecycle / token-client

This PR is intentionally auth-only. The execute-side folder move and full execute-context cleanup stay in the next stacked PR.

Testing

Manual checks:

pnpm run shopify store auth --store donaldmerand.myshopify.com --scopes read_products
pnpm run shopify store execute --store donaldmerand.myshopify.com --query 'query { shop { name id } }'
node packages/cli/bin/run.js store auth --help
node packages/cli/bin/run.js store execute --help

Verify that:

• store auth still authenticates and persists store auth successfully
• store execute still reuses stored auth successfully
• help/runtime wiring still works after the auth file move

Considered

• Fold execute into this PR: deferred so auth ownership can be reviewed on its own.
• Introduce generic persistence / transport folders: rejected in favor of domain-first store/auth ownership.
• Keep the old stored-session getter naming: renamed now so current-user semantics are explicit before we build on them.

Measuring impact

• 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

[dmerand]

• Add/enforce --json and output boundary for store commands #7190
• Store execute restructure #7188
• Store auth restructure #7187 👈 (View in Graphite)
• Make store auth scopes additive #7172 : 1 other dependent PR (#7184 )
• main

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

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

Caution

DO NOT create changesets for features which you do not wish to be included in the public changelog of the next CLI release.

[ryancbahan]

total nit from me: i am very against index files. they obscure intent and become a dumping ground, plus barrel files cause circular deps and tree shaking issues in many cases

[dmerand]

Fair nit. I’m using index.ts here as the auth module entrypoint/orchestrator rather than as a barrel export, so I’m inclined not to rename it just for this PR. If it starts turning into a grab-bag again, I’d rather fix that by tightening the module boundary than by just changing the filename.

[ryancbahan]

nit: have a views dir?

[dmerand]

We have one view right now and I didn't want this refactor to go too far. I'm not sure if our domain needs "views" yet. But I'm noting for posterity that I would be aligned with adding this when our views increase here.

[ryancbahan]

odd to create a dedicated server as a closure in a callback, no?

[ryancbahan]

odd to create a dedicated server as a closure in a callback, no?

[ryancbahan]

I like the direction of this pr, but the seams still seem a little unclear to me. I wonder if we can invert the order of initialization a bit -- especially in callback and pkce files -- so that we first initialize the server explicitly, initialize the persistence stores, establish the dynamic route(s) that need to be hit, and then let the callback chain(s) flow.

[ryancbahan]

I don't know that the DI pattern here is particularly serving us

[dmerand]

That's fair, it's unique to this flow and somewhat unusual in the codebase. It wasn't bothering me in the original implementation because the flow is bounded, but this version of the implementation isn't necessarily as clear. I'll see what the alternative looks like.

[dmerand]

I've adjusted the implementation to consolidate the DI object + make it authoritative. That'll make it easier to refactor out later, which I'm not opposed to doing.

[dmerand]

I like the direction of this pr, but the seams still seem a little unclear to me. I wonder if we can invert the order of initialization a bit -- especially in callback and pkce files -- so that we first initialize the server explicitly, initialize the persistence stores, establish the dynamic route(s) that need to be hit, and then let the callback chain(s) flow.

I looked at whether there was a smaller callback extraction that would materially clarify ownership here without turning into a larger redesign. The only bounded version I found was splitting server lifecycle from callback request handling, but it didn’t feel like enough improvement to justify more churn in this PR after the other seam cleanups. So I’d keep the larger callback/pkce lifecycle inversion as follow-up work rather than half-landing it here.