fix(appsync-modelgen-plugin): replace relay 12 dependency chain

[michaelgiraldo]

Summary

Replaces the relay-compiler@12 dependency chain in @aws-amplify/appsync-modelgen-plugin.

This addresses the appsync-modelgen-plugin subset of aws-amplify/amplify-backend#3062 and overlaps the broader fresh-install issue in aws-amplify/amplify-backend#3135.

Changes

• Upgraded the package to the newer @graphql-codegen/visitor-plugin-common / @graphql-codegen/plugin-helpers / @graphql-tools/utils line that resolves @graphql-tools/relay-operation-optimizer@7.1.2 -> @ardatan/relay-compiler@13.0.1
• Adapted the package-owned scalar maps to the newer normalized scalar contract used by GraphQL Code Generator
• Updated visitor code to resolve scalar output types explicitly so generated Java, Dart, metadata, and model introspection output remain stable
• Made codegenVersion optional in RawAppSyncModelConfig to match existing package usage in tests and callers
• Added a minimal Disposable / AsyncDisposable ambient declaration for this package so it remains buildable under the repo's current TypeScript 4.7 floor while using newer graphql-tools type declarations

Strategy

This chain is owned by @aws-amplify/appsync-modelgen-plugin, so a downstream-only fix in amplify-backend would not remove it.

The main migration work here was not the dependency bump itself. The newer GraphQL Code Generator packages normalize scalar mappings as { input, output } objects instead of plain strings, so the package code had to be updated to use those mappings explicitly. Without that adaptation, generated output regressed and language-specific tests failed.

The Disposable compatibility declaration is a temporary build-floor bridge, not a runtime change. The repo still pins TypeScript 4.7.4, while newer graphql-tools type declarations reference the standard Disposable globals introduced in later TypeScript lib definitions. This package does not use those contracts directly, so the ambient declaration keeps the package buildable until the repo's TypeScript floor moves forward.

Verification

• npx -y yarn@1.22.22 workspace @aws-amplify/appsync-modelgen-plugin build
• npx -y yarn@1.22.22 workspace @aws-amplify/appsync-modelgen-plugin test --runInBand
• Fresh temp install with published @aws-amplify/appsync-modelgen-plugin@2.15.2 showed:
  • @graphql-codegen/visitor-plugin-common@1.22.0 -> @graphql-tools/relay-operation-optimizer@6.5.18 -> @ardatan/relay-compiler@12.0.0 -> glob@7.2.3 -> inflight@1.0.6
  • deprecated @babel/plugin-proposal-class-properties and @babel/plugin-proposal-object-rest-spread
• Fresh temp install with the local packed tarball showed:
  • @graphql-tools/relay-operation-optimizer@7.1.2 -> @ardatan/relay-compiler@13.0.1
  • no glob@7
  • no inflight
  • no deprecated Babel proposal plugin warnings during install
  • 0 vulnerabilities

Maintainer Context

This PR is the second narrow package-owned slice of the deprecated dependency chain tracked in aws-amplify/amplify-backend#3062.

The companion PR #1012 addresses the separate @aws-amplify/graphql-types-generator Babel 6 / core-js@2 / rimraf@3 path. Together, those two PRs cover the main amplify-codegen-owned subtrees from the current repro.

Downstream work is still required after release so amplify-backend can consume the published packages, and aws-amplify/amplify-backend#3135 remains broader than the codegen-owned surface.

Maintainer Ask

If this approach looks acceptable, please review this as an independent appsync-modelgen-plugin fix. Once merged and released, downstream repos can consume the published package and re-measure the broader fresh-install impact.

[michaelgiraldo]

Small scope clarification on this PR:

This PR is still intended to be the narrow @aws-amplify/appsync-modelgen-plugin dependency-chain fix only.

The Disposable compatibility declaration here is a temporary build-floor bridge because the repo currently pins TypeScript 4.7 while the newer graphql-tools type declarations reference later standard lib globals. I am intentionally not folding the broader monorepo TypeScript/Jest toolchain upgrade into this PR, because that is a separate repo-wide change with a much larger review surface.

I have a local prototype for that broader TypeScript/Jest floor work, but I am keeping it separate from this PR on purpose. For this PR, the review question is only whether the package-scoped dependency-chain migration is acceptable on its own.

If maintainers would prefer the broader toolchain work to be proposed, I can open that as a separate follow-up PR.

[michaelgiraldo]

Follow-up note: the broader monorepo TypeScript/Jest floor work is now proposed separately in #1014.

That follow-up is intended to remove the need for the temporary Disposable compatibility bridge without expanding the review scope of this package-level PR.