feat: load GTM via @next/third-parties gated by NEXT_PUBLIC_GTM_ID#501
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
LGTM — clean switch to @next/third-parties, properly gated on NEXT_PUBLIC_GTM_ID.
Extended reasoning...
Overview
Swaps the hand-rolled GTM next/head + Script snippet (with a hardcoded container ID and a NODE_ENV gate) for the official GoogleTagManager component from @next/third-parties/google, conditionally rendered only when NEXT_PUBLIC_GTM_ID is set. Also adds the env var to the client zod schema and .env.example, drops the now-unused GTMHead/GTMBody module, and removes the stray next/head import (which is a no-op in the App Router anyway).
Security risks
None material. GTM loading behavior is unchanged in intent (still injects the same third-party tag manager); the container ID moves from a hardcoded literal to a client env var, which is fine since GTM container IDs are public. Gating on presence of the env var means preview deploys will no longer load GTM, which is the stated intent.
Level of scrutiny
Low. Small, mechanical migration to the framework-supported component, no logic in critical code paths (auth, billing, permissions). The zod schema addition is standard (z.string().min(1).optional()), matching the surrounding NEXT_PUBLIC_POSTHOG_KEY pattern.
Other factors
Bug hunting system found nothing. Vercel preview build is running. No prior reviewer comments to address.
Replaces the hand-rolled GTM snippet (hardcoded container ID,
NODE_ENVgate,next/headusage unsupported in the App Router) with the GoogleTagManager component. The container ID now comes fromNEXT_PUBLIC_GTM_ID, so GTM loads only where the var is set — production, not preview deploys.part of DASH-159