The Twitter metadata renderer emitted `twitter:app:*` tags whenever a
`twitter.app` object was present and `twitter:player:*` tags whenever
`twitter.players` was present, regardless of the resolved card type. It also
emitted `twitter:app:id`/`twitter:app:url` for falsy values (`0`, `""`).
Next.js gates these blocks on the resolved card: `if (card === 'app')` and
`if (card === 'player')`, and uses truthy checks for app id/url. Mirror that:
gate the app block on `card === 'app'`, the player block on `card === 'player'`,
and skip falsy app ids/urls. The card is already defaulted in
postProcessMetadata (summary_large_image / summary), matching Next.js.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Locks in the fix from #1436: when `metadataBase` is configured (on a parent
layout) and `generateImageMetadata` produces multiple dynamic icon /
apple-icon images, the rendered `<link>` href values must stay relative,
matching Next.js behavior in
test/e2e/app-dir/metadata-dynamic-routes/index.test.ts ("should support
generate multi images with generateImageMetadata").
The existing unit-level coverage in features.test.ts verifies MetadataHead
output directly. This adds an integration test through the full pipeline
(applyFileBasedMetadata -> MetadataHead) covering route groups, dynamic
segments, and parent-layout metadataBase inheritance — the exact shape of
the failing Next.js deploy test in #1493.
Refs #1493
Xplod13