refactor!: remove unused asset types and splash scaffolding

[trevor-lambert]

Description

Deletes unused types and scaffolding from src/project/assets/. Deletion only — no behaviour changes. +1 −154 across 5 files; the single insertion is an import line losing one unused name.

This started from an observation that several AssetKind variants looked unused. Investigation showed only one actually was (NotificationIcon); the real dead weight was the splash/PWA scaffolding surrounding it.

Removed from the public API

Symbol	Kind
Assets	interface
AssetKind.NotificationIcon	runtime enum member
Orientation	runtime enum
Theme	runtime enum
IosContents	interface
IosOutputAssetTemplateIcon	type alias
IosOutputAssetTemplateSplash	interface
AndroidOutputAssetTemplateSplash	interface
PwaOutputAssetTemplate	interface

Removed internally (zero-reference)

• MobileProject.assets — declared, always null, never read. assetDir is kept; it's still used by assetDirExists().
• AndroidAssetGenerator._generateSplashesFromLogo — uncallable: there is no splash AssetKind and no splash template exists in android/assets.ts.
• AssetGeneratorOptions: splashBackgroundColor, splashBackgroundColorDark, pwaManifestPath, pwaNoAppleFetch, logoSplashScale, logoSplashTargetWidth.
• Now-dead imports (Logger, relative), the commented-out iOS splash constants, and an unused iosDir local.

Change Type

• Fix
• Feature
• Refactor
• Breaking Change
• Documentation
• Other (CI, chores, etc.)

Rationale / Problems Fixed

src/project/assets/ is a partially-ported fork of Ionic's Trapeze. Several families of types came across and then never acquired a consumer:

• There is no assets YAML operation, so the pipeline is unreachable from the configure CLI.
• Nothing in this repo ever constructs an InputAsset — it's an API-only surface.
• No splash or PWA generator was ever ported, but their template types, options and enums all shipped.

tsc --strict never flagged any of this because nothing referenced it at all. The result was a public API advertising capabilities the package does not have — Assets offers splash, pwaIcon and androidNotificationIcon slots that nothing can consume, and AssetKind.NotificationIcon silently returns [] from both generators.

AssetKind keeps its 6 live variants: Logo, LogoDark, AdaptiveIcon, Icon, IconForeground, IconBackground.

Breaking change notes

asset-types.ts is re-exported from src/project/index.ts, so all of the above are part of the published @capacitor/trampoline surface. Orientation and Theme are value enums, so their removal is a runtime break, not just a type-level one — a consumer importing them gets undefined. The rest are type-only and fail at compile time.

AssetGeneratorOptions is not itself exported, but its fields are reachable structurally via new AndroidAssetGenerator({ ... }); an object literal passing a removed key now produces an excess-property error. Minor, but worth knowing.

Deliberately NOT fixed

generateAdaptiveIconForeground and generateAdaptiveIconBackground filter templates by AssetKind.Icon — the legacy 36–192px mipmaps — then as-cast the result to AndroidOutputAssetTemplateAdaptiveIcon, so adaptive layers are written at legacy sizes rather than the 81–432px adaptive sizes defined in android/assets.ts. The cast is what hides it from the compiler. The logo path filters correctly on AssetKind.AdaptiveIcon, so the same enum drives two paths and only one is right. This dates back to 40737a8.

Left untouched here to keep this PR deletion-only — feat/RDMR-1476/android-adaptive-icon already addresses it.

Tests or Reproductions

This repo has no test suite and CI runs only npm ci && npm run build, so tsc is the entire safety net. That is adequate for this particular change because it is pure deletion: anything still referenced fails to compile.

Verification performed:

1. npm run build — passes clean.
2. grep -rn over src/ for every removed symbol — no residual references.
3. git diff src/project/assets/android/generator.ts — confirmed the two AssetKind.Icon filter lines are unchanged, i.e. no behavioural drift.
4. Rebuilt dist/ and confirmed the runtime export list is now AssetKind, Platform, Format, AndroidDensity, IosIdiom, with AssetKind holding exactly the 6 remaining values.

Not done: an end-to-end generator run against a real Capacitor project. There is no fixture in-repo for it, and since no code path changed, the tsc gate covers the risk.

Screenshots / Media

n/a

Platforms Affected

• Android
• iOS
• Web

Both platform generators are touched, but only by removal of unreachable code — no generated output changes on either. PWA/web types were removed too, though no web generator has ever existed.

Notes / Comments

Neither switch over AssetKind has an exhaustiveness check, which is why this drifted silently in the first place. I did not add one here: default: assertNever(...) will not compile while AdaptiveIcon remains intentionally unhandled in both generators (it is a template-only kind, never a valid input kind). Worth a follow-up that pairs the exhaustiveness check with a decision about whether input kinds and output-template kinds belong in the same enum at all.

Also worth flagging for whoever picks that up: IosAssetGenerator.updateIconsContentsJson calls rmSync inside a .map over every existing Contents.json entry, for every generated asset. It will throw if a listed file is already missing. Out of scope here.

🤖 Generated with Claude Code