Rename "packages" to "integrations" in aspire.config.json with backward compatibility

[Copilot]

Description

Renames the "packages" JSON key to "integrations" in aspire.config.json while maintaining full backward compatibility. The system reads both "packages" (legacy) and "integrations" (new) keys, but always writes "integrations" in new or saved files.

Changes

• AspireConfigFile.cs: Changed [JsonPropertyName("packages")] → [JsonPropertyName("integrations")] on the Packages property. Added a LegacyPackages property with [JsonPropertyName("packages")] for backward-compatible reading, with MergeLegacyPackages() to merge legacy entries into Packages after deserialization. When both keys exist, "integrations" takes precedence. LegacyPackages is nulled after merge and excluded from serialization via WhenWritingNull.
• extension/src/utils/cliTypes.ts: Added integrations? to AspireConfigFile interface; kept packages? with @deprecated marker for backward compatibility.
• extension/schemas/aspire-config.schema.json: Added "integrations" property and kept "packages" as deprecated for backward compatibility.
• 149 playground aspire.config.json files: Updated key from "packages" to "integrations".
• Tests: Updated ProjectReferenceTests.cs and ConfigMigrationTests.cs to use "integrations". Added 5 new backward-compatibility tests in AspireConfigFileTests.cs covering: reading legacy "packages" key, reading new "integrations" key, merging both keys, precedence when both exist, and verifying only "integrations" is written on save.

Before / After:

// Before (still readable for backward compat)
{
  "packages": { "Aspire.Hosting.Redis": "9.2.0" }
}

// After (always written in new files)
{
  "integrations": { "Aspire.Hosting.Redis": "9.2.0" }
}

Note: The legacy .aspire/settings.json format (AspireJsonConfiguration) retains its "packages" key unchanged — that format is migrated into aspire.config.json on first use.

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire.dev issue:
      • New issue
  • No

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[davidfowl]

@copilot This needs to be backwards compatible. We need to support both now for reading (both packages and integrations) but write integrations in anything new.

[Copilot]

@copilot This needs to be backwards compatible. We need to support both now for reading (both packages and integrations) but write integrations in anything new.

Added backward compatibility in a25121c. Now:

• Reading: Both "packages" (legacy) and "integrations" (new) keys are supported. A LegacyPackages property reads "packages", and MergeLegacyPackages() merges entries into Packages after deserialization. When both exist, "integrations" takes precedence.
• Writing: Always writes "integrations" — LegacyPackages is nulled after merge and excluded via WhenWritingNull.
• JSON schema and TypeScript interface both accept either key.
• 5 new tests cover: reading legacy key, reading new key, merging both, precedence, and verifying only "integrations" is written.