Remove packageManager, nodeDependencies, usesWorkspaces from App

[ryancbahan]

WHY are these changes introduced?

Depends on #7023. The App object currently acts as a god object, carrying environment concerns like packageManager, nodeDependencies, and usesWorkspaces alongside configuration data. With the Project model now owning these fields, services should receive them as explicit dependencies rather than reaching into App.

WHAT is this pull request doing?

Removes packageManager, nodeDependencies, usesWorkspaces fields and the updateDependencies() method from AppInterface and App class. Services now receive a Project instance explicitly:

• AppInterface / App — removed the three fields and updateDependencies()
• Options types — added project: Project to BuildOptions, DevOptions, DeployOptions, GenerateOptions, GenerateExtensionTemplateOptions
• localAppContext — now returns {app, project} so commands can destructure and pass project through
• installAppDependencies — takes Project instead of AppInterface
• info — takes project param; backward compat in --json output preserved by injecting project fields into serialized output
• loadOpaqueApp — surfaces packageManager for the link flow
• Test infra — added testProject() helper, updated all affected tests

How to test your changes?

1. pnpm type-check --projects=app passes
2. npx vitest run packages/app/ passes
3. Verify shopify app info --json still includes packageManager, nodeDependencies, usesWorkspaces in output

Measuring impact

• n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix

Checklist

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

[ryancbahan]

• Remove packageManager, nodeDependencies, usesWorkspaces from App #7035 👈 (View in Graphite)
• Integrate Project model into loader and decompose into composable stages #7023
• Add Project domain model for filesystem abstraction #7022
• 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/public/node/themes/api.d.ts

@@ -5,7 +5,6 @@ export type ThemeParams = Partial<Pick<Theme, 'name' | 'role' | 'processing' | '
 export type AssetParams = Pick<ThemeAsset, 'key'> & Partial<Pick<ThemeAsset, 'value' | 'attachment'>>;
 export declare function fetchTheme(id: number, session: AdminSession): Promise<Theme | undefined>;
 export declare function fetchThemes(session: AdminSession): Promise<Theme[]>;
-export declare function findDevelopmentThemeByName(name: string, session: AdminSession): Promise<Theme | undefined>;
 export declare function themeCreate(params: ThemeParams, session: AdminSession): Promise<Theme | undefined>;
 export declare function fetchThemeAssets(id: number, filenames: Key[], session: AdminSession): Promise<ThemeAsset[]>;
 export declare function deleteThemeAssets(id: number, filenames: Key[], session: AdminSession): Promise<Result[]>;

packages/cli-kit/dist/public/node/themes/theme-manager.d.ts

@@ -8,8 +8,8 @@ export declare abstract class ThemeManager {
     protected abstract removeTheme(): void;
     protected abstract context: string;
     constructor(adminSession: AdminSession);
-    findOrCreate(name?: string, role?: Role): Promise<Theme>;
-    fetch(name?: string, role?: Role): Promise<Theme | undefined>;
+    findOrCreate(): Promise<Theme>;
+    fetch(): Promise<Theme | undefined>;
     generateThemeName(context: string): string;
     create(themeRole?: Role, themeName?: string): Promise<Theme>;
 }
\ No newline at end of file

[github-actions]

Coverage report

St.❔	Category	Percentage	Covered / Total
🟢	Statements	82.16%	14931/18172
🟡	Branches	74.51%	7376/9899
🟢	Functions	81.29%	3776/4645
🟢	Lines	82.55%	14118/17102

Test suite run success

3933 tests passing in 1514 suites.

Report generated by 🧪jest coverage report action from f8d9783

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

[dmerand]

LGTM! My robot buddies had a couple of doc/test suggestions, but they're non-blocking.

[dmerand]

💡 Improvement: The removal of packageManager, nodeDependencies, and usesWorkspaces from AppInterface represents a significant architectural shift from a 'god object' pattern to separated concerns. While the code changes are clean, there's no documentation explaining why certain fields live in Project vs App, which could help future contributors understand the boundary and maintain it correctly.

Suggestion: Add JSDoc comments to both AppInterface and Project explaining the separation of concerns: AppInterface owns app-level configuration and extensions, while Project owns filesystem/environment infrastructure (package manager, dependencies, workspace detection). This would make the architectural intent explicit and help maintainers preserve the boundary.

[dmerand]

💬 Suggestion: The reloadApp() function re-scans the filesystem via getAppConfigurationContext() on each reload, creating a fresh Project instance rather than persisting it in memory. This is likely correct for detecting new config files and extensions during dev sessions.

However, it's worth verifying through integration tests that:

1. Filesystem changes (new extensions, configs) are properly picked up on reload
2. Project re-scanning doesn't break dev session state
3. Performance remains acceptable for repeated Project.load() calls

Previous PRs mentioned performance improvements from reducing scans - worth confirming those hold true in the reload path.

Suggestion: Add integration tests covering:

test('reloadApp picks up new extension added to filesystem', async () => {
  const app1 = await loadApp(...)
  await writeExtensionToml(...) // Add new extension to disk
  const app2 = await reloadApp(app1)
  expect(app2.allExtensions.length).toBe(app1.allExtensions.length + 1)
})

test('Project.load() performance acceptable for dev reload frequency', async () => {
  // Measure Project.load() time for typical app size
  // Verify it's under threshold (e.g., 100ms) for good dev UX
})

[ryancbahan]

this exact test is covered in the previous pr 👍