Fetch management_experience from App Management API

[gonzaloriestra]

WHY are these changes introduced?

Related to https://github.com/shop/issues-develop/issues/469

When fetching the active app release with its extensions, we were incorrectly assuming all of them were cli managed.

WHAT is this pull request doing?

⚠️ This PR requires https://github.com/shop/world/pull/115323 to be released first

Uses the new management_experience field from the API to find out the dashboard managed extensions.

How to test your changes?

• p shopify app import extensions with App Management API

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

[gonzaloriestra]

• Add import extensions functionality on deploy #6136
• Fetch management_experience from App Management API #6149 👈 (View in Graphite)
• Refactor import-extensions #6134
• 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/common/version.d.ts

@@ -1 +1 @@
-export declare const CLI_KIT_VERSION = "3.83.0";
\ No newline at end of file
+export declare const CLI_KIT_VERSION = "3.82.0";
\ No newline at end of file

[github-actions]

Coverage report

St.❔	Category	Percentage	Covered / Total
🟡	Statements	78.2% (+0.22% 🔼)	13090/16739
🟡	Branches	72.22% (+0.11% 🔼)	6369/8819
🟡	Functions	78.32% (+0.14% 🔼)	3393/4332
🟡	Lines	78.59% (+0.21% 🔼)	12392/15768

Show files with reduced coverage 🔻

St.❔	File	Statements	Branches	Functions	Lines
🟢	... / file-uploader.ts	89.29% (-0.51% 🔻)	71.88% (-3.13% 🔻)	100%	88.89% (-0.69% 🔻)
🔴	... / flags.ts	28.57% (-21.43% 🔻)	0% (-100% 🔻)	25% (-8.33% 🔻)	28.57% (-21.43% 🔻)
🟢	... / local-storage.ts	100%	54.55% (-4.55% 🔻)	100%	100%
🔴	... / theme-store.ts	0% (-80% 🔻)	0% (-75% 🔻)	0% (-100% 🔻)	0% (-80% 🔻)

Test suite run success

3078 tests passing in 1320 suites.

Report generated by 🧪jest coverage report action from 4ca13b0

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

[isaacroldan]

I was going to say that you could just hardcode the specification_identifiers that can should imported when running deploy, since it's a small subset, but if it's already done that's fine!

[gonzaloriestra]

I was going to say that you could just hardcode the specification_identifiers that can should imported when running deploy, since it's a small subset, but if it's already done that's fine!

I thought about that, because we actually have a hardcoded list of identifiers for config extensions, but I think this is the right way to do it.