Use Project follow-up command helper for display-only paths

[dmerand]

What

This follow-up continues the same package-manager stack as #7239, #7241, and #7242.

Add a formatProjectFollowUpCommand(...) helper for Project-backed follow-up commands, and use it in the display-only callers in deploy, dev, info, and generate instead of formatting commands from project.packageManager directly.

Why

The stack goal is to make callers choose intent, not implementation.

#7242 added an explicit package-manager boundary for project operations. This PR applies the same idea to display-only paths: when a caller only needs the right follow-up command for a project, it should ask for that command shape instead of reaching into package-manager state and formatting it itself.

This keeps the slice narrow. It does not change the package-manager values still surfaced for project info output, and it does not reopen the loader/config-link paths.

How

Add formatProjectFollowUpCommand(...) in packages/app/src/cli/utilities/project-command.ts.

Use it from:

• deploy completion messaging
• dev scope mismatch warnings
• info follow-up messaging
• generate success messaging

[dmerand]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• Use Project follow-up command helper for display-only paths #7243 👈 (View in Graphite)
• Require explicit package manager for project operations #7242
• Add root-known package manager helper #7241
• Use function directory package manager for GraphQL typegen #7239
• main

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

[afurm]

Solid refactoring — introducing formatProjectFollowUpCommand as an explicit boundary between callers and packageManager state is the right abstraction. A few questions:

1. Does the helper guard against invalid/unknown package managers at display time?

The PR description says this is the "display-only" sibling to #7242's operation-gating. I notice formatProjectFollowUpCommand internally calls project.packageManager — which may still return 'unknown' for projects without a package.json. Does the helper degrade gracefully in that case (e.g., show a plain shopify command), or could users see unknown shopify app deploy in the output? If the latter, it might be worth adding a fast-path guard here too, even if display-only.

2. Is there a race between Project.load() and project.packageManager access?

In the deploy.ts and dev.ts callers, project is already loaded. But if these helpers are ever called before the Project is fully resolved, does project.packageManager always return a valid value, or could it throw? Worth adding a comment or a defensive fallback.

3. Test coverage for the new helper

The PR touches 5 files but I don't see a dedicated unit test for formatProjectFollowUpCommand itself. Are there integration tests that cover the display paths, or should there be a focused unit test for the helper with various packageManager values ('npm', 'yarn', 'unknown', '')?

[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/public/node/node-package-manager.d.ts

@@ -27,6 +27,7 @@ export type DependencyType = 'dev' | 'prod' | 'peer';
  */
 export declare const packageManager: readonly ["yarn", "npm", "pnpm", "bun", "homebrew", "unknown"];
 export type PackageManager = (typeof packageManager)[number];
+export type ProjectPackageManager = Extract<PackageManager, 'yarn' | 'npm' | 'pnpm' | 'bun'>;
 /**
  * Returns an abort error that's thrown when the package manager can't be determined.
  * @returns An abort error.
@@ -68,6 +69,58 @@ export declare function packageManagerFromUserAgent(env?: NodeJS.ProcessEnv): Pa
  * @returns The dependency manager
  */
 export declare function getPackageManager(fromDirectory: string): Promise<PackageManager>;
+/**
+ * Resolves the package manager for a directory already known to be the project root.
+ *
+ * Use this when the caller already knows the root directory and wants to inspect that root
+ * directly rather than walking upward from a child directory.
+ *
+ * @param rootDirectory - The known project root directory.
+ * @returns The package manager detected from root markers, defaulting to npm <command>
+
+Usage:
+
+npm install        install all the dependencies in your project
+npm install <foo>  add the <foo> dependency to your project
+npm test           run this project's tests
+npm run <foo>      run the script named <foo>
+npm <command> -h   quick help on <command>
+npm -l             display usage info for all commands
+npm help <term>    search for help on <term>
+npm help npm       more involved overview
+
+All commands:
+
+    access, adduser, audit, bugs, cache, ci, completion,
+    config, dedupe, deprecate, diff, dist-tag, docs, doctor,
+    edit, exec, explain, explore, find-dupes, fund, get, help,
+    help-search, init, install, install-ci-test, install-test,
+    link, ll, login, logout, ls, org, outdated, owner, pack,
+    ping, pkg, prefix, profile, prune, publish, query, rebuild,
+    repo, restart, root, run-script, sbom, search, set,
+    shrinkwrap, star, stars, start, stop, team, test, token,
+    undeprecate, uninstall, unpublish, unstar, update, version,
+    view, whoami
+
+Specify configs in the ini-formatted file:
+    /home/runner/work/_temp/.npmrc
+or on the command line via: npm <command> --key=value
+
+More configuration info: npm help config
+Configuration fields: npm help 7 config
+
+npm@11.3.0 /opt/hostedtoolcache/node/24.1.0/x64/lib/node_modules/npm when no marker exists.
+ * @throws PackageJsonNotFoundError if the provided directory does not contain a package.json.
+ */
+export declare function getPackageManagerForProjectRoot(rootDirectory: string): Promise<ProjectPackageManager>;
+/**
+ * Builds the command and argv needed to execute a local binary using the package manager
+ * detected from the provided directory or its ancestors.
+ */
+export declare function packageManagerBinaryCommandForDirectory(fromDirectory: string, binary: string, ...binaryArgs: string[]): Promise<{
+    command: string;
+    args: string[];
+}>;
 interface InstallNPMDependenciesRecursivelyOptions {
     /**
      * The dependency manager to use to install the dependencies.