@aws-amplify/core (v5) declares tslib ^1.8.0 but emits __spreadArray (latent __spreadArray-is-not-a-function risk)

Summary

On the v5 line (v5-stable), @aws-amplify/[email protected] declares "tslib": "^1.8.0" but its emitted lib/ calls tslib.__spreadArray, which only exists in tslib ≥ 2.1.0. ^1.8.0 means >=1.8.0 <2.0.0, so it can only ever resolve [email protected] — which does not export __spreadArray.

This is the same class of bug as #14865 (fixed for @aws-amplify/datastore in #14878): a package whose compiled output needs tslib >= 2.1 but whose declared tslib range does not guarantee it, so a consumer can hit __spreadArray is not a function at bundle/runtime. core simply wasn't part of the #14865 regression, so it has gone unnoticed.

Filing as a separate follow-up per review of #14878, which was intentionally kept datastore-only.

Root cause

All v5 packages compile with target: es5 + downlevelIteration: true + importHelpers: true (packages/tsconfig.base.json), so their emitted lib/ imports TypeScript helpers from tslib. __spreadArray (the TS 4.2+ helper) is only present in tslib ≥ 2.1.0:

tslib	__spread	__spreadArray
1.14.1 (max of ^1.8.0)	function	undefined
2.0.3	function	undefined
2.1.0+	function	function

@aws-amplify/[email protected] emits tslib.__spreadArray in its published lib/ (4 files) yet pins tslib: ^1.8.0. If a consumer's tree resolves core's tslib import to a 1.x copy, core throws __spreadArray is not a function — identical to the datastore failure in #14865.

Note this is not a new regression: [email protected] (in the working [email protected]) already emitted __spreadArray with the same ^1.8.0 pin. It is a latent inconsistency that happens to be masked in most trees (a modern [email protected] is usually hoisted and resolved), but it is not guaranteed and can crash under the same peer-dependency conditions described in #14865 (e.g. a peer such as apollo-boost pulling [email protected]).

Scope — stale ^1.8.0 pins on v5-stable

The following v5 packages declare tslib: ^1.8.0:

package (v5-stable)	pins tslib	currently emits __spreadArray?
@aws-amplify/core (5.8.18)	^1.8.0	yes (4 files) — active latent crash risk
@aws-amplify/api	^1.8.0	no (today)
@aws-amplify/api-graphql	^1.8.0	no (today)
@aws-amplify/api-rest	^1.8.0	no (today)
@aws-amplify/auth	^1.8.0	no (today)
@aws-amplify/pubsub	^1.8.0	no (today)
@aws-amplify/cache	^1.8.0	no (today)

core is the one that currently emits __spreadArray, so it is the active risk. The others don't emit it today, but their ^1.8.0 pins are the same latent trap datastore fell into — a routine TypeScript-emit change (exactly what flipped datastore's __spread → __spreadArray between 4.7.24 and 4.7.26) would break them the same way.

Suggested fix

Bump tslib to ^2.1.0 (the version that introduced __spreadArray; ^2.0.0 is insufficient since 2.0.x still lacks it) for @aws-amplify/core — and, for consistency/robustness, for the other stale ^1.8.0 pins (api, api-graphql, api-rest, auth, pubsub, cache). This matches the fix applied to datastore in #14878 and the aws-amplify meta-package, which already depends on tslib ^2.0.0.

Related

• Same class as #14865 (datastore __spreadArray is not a function)
• Fixed for datastore in #14878