feat(banner): add maintenance-mode banner to Amplify JavaScript v5 pages - #8620
Conversation
Amplify JavaScript v5 is in maintenance mode, but v5 docs pages gave no in-page signal or upgrade path. This adds a banner to all Amplify JavaScript v5 pages pointing users at the v5 -> v6 migration guide. v5 pages are the 'prev' version of the JS-family platforms and live under /gen1/<js-platform>/prev/... (PLATFORM_VERSIONS maps prev -> v5 for every JS platform), so detection is route-based and mirrors the existing isGen1 check in Layout. - JsV5MaintenanceBanner mirrors the existing Gen1Banner markup/styling - isJsV5Page util for route detection, with unit tests - rendered from Layout alongside the Gen1 banner
osama-rizk
left a comment
osama-rizk
left a comment
There was a problem hiding this comment.
Clean, well-scoped change and the detection logic is correct — I verified isJsV5Page returns true for all six JS platforms' prev routes and false for non-JS prev (v1), v6, gen2, and empty paths, and that Layout feeds it the real URL (consistent with isGen1). Test coverage is genuinely good for a banner.
One note on the description: it says this "mirrors the existing Gen 1 maintenance banner mechanism." It mirrors Gen1Banner's markup, but not its link style (Gen1Banner uses relative links) or its platform-awareness (Gen1Banner takes currentPlatform) — see the inline notes on the link.
Findings inline are all low-to-medium: one that matters for the next version cycle (route detection derives v5 from a proxy rather than PLATFORM_VERSIONS), a link-portability one (absolute prod URL for a same-site page), plus a few consistency/UX nits.
- isJsV5Page now reads PLATFORM_VERSIONS instead of inferring v5 from (gen1 + prev + JS platform), so the banner cannot outlive v5 when a platform's prev rolls forward. The 'prev' segment check is retained, as PLATFORM_VERSIONS alone cannot distinguish a prev route from a current one. - Migration guide link is now root-relative, so preview/staging/localhost no longer jump to production docs, and navigation stays client-side. - Banner takes currentPlatform and links within the reader's platform, matching Gen1Banner, rather than sending every reader to the javascript guide. - Extracted %page-banner placeholders shared by the Gen1, Gen2 and v5 banners, collapsing the styles that were duplicated 3x. Computed styles for the two pre-existing banners are byte-identical (verified against compiled CSS). - v5 banner is now a lighter left-accented variant with an outlined badge so it no longer reads as a second identical amber banner beneath the Gen1 banner.
|
Thanks for the thorough review — all five inline findings are addressed in 6870fe2, with a reply on each thread. |
|
Tick the box to add this pull request to the merge queue (same as
|
3 participants
Description of changes
Amplify JavaScript v5 is in maintenance mode, but the v5 documentation pages currently give readers no in-page signal of that, and no pointer to the upgrade path. Readers can land on a v5 page from search and follow deprecated guidance without realizing a newer major version exists.
This adds a maintenance-mode banner to all Amplify JavaScript v5 pages, linking to the v5 → v6 migration guide.
Banner copy:
Implementation
src/components/JsV5MaintenanceBanner/— new component. FollowsGen1Banner's conventions: takescurrentPlatformand builds a root-relative, platform-aware link, so a reader on/gen1/vue/prev/...goes to the Vue guide and stays within the current environment (no jump to production docs from a preview build).src/utils/isJsV5Page.ts— route detection. v5 pages live under/gen1/<platform>/prev/..., and which versionprevresolves to is read fromPLATFORM_VERSIONS(v5 for JS platforms, v1 for Android/Swift/Flutter) rather than inferred from the platform, so the banner can't outlive v5 when a platform'sprevrolls forward.src/components/Layout/Layout.tsx— renders the banner alongside the existingGen1Banner/Gen2MaintenanceBannercalls.src/styles/global-nav.scss— extracted shared%page-bannerplaceholders now used by all three banners (the styles were about to be duplicated a third time). The v5 banner is a deliberately lighter left-accented variant with an outlined badge, so it reads as a version-specific sub-notice beneath the Gen1 banner instead of a second identical amber banner. Net compiled CSS: 79,336 → 78,250 bytes.Verification
Unit tests (9, new) —
yarn test:unit:Against a running dev server (
next dev), inspecting rendered HTML:/gen1/react/prev/...and/gen1/javascript/prev/..., with a platform-correct root-relative href:/gen1/react/build-a-backend/...(Gen 1, v6),/gen1/swift/prev/...(non-JSprev= v1), and/react/build-a-backend/...(Gen 2).styles.scssbefore/after and compared effective declarations for every pre-existing banner selector (including dark-mode variants) — all identical; only declaration order changed.eslintclean on changed files;prettierreports no changes wanted on any added line.Not verified: no rendered screenshot — Playwright isn't available in my environment, so the visual claims come from compiled CSS + rendered HTML. Worth an eyeball on the preview build.
One open product question: unlike the Gen 1 banner, this copy names no end-of-life date, because I found no published EOL date for JS v5. If one is committed, that sentence should be added.
Checklist
yarn test:unitpassesBy submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.