fix: bump Cloudinary Video Player to 4.1.2

[adimiz1]

Summary

CldVideoPlayer loads cloudinary-video-player@1.11.1 from unpkg via a hardcoded PLAYER_VERSION. That release is from March 2024; the current player is 4.1.2.

Why now: 1.11.1's analytics plugin checks window.ga once at setup and then calls window.ga(...) unguarded on every tracked event. On GA4 / Google Tag Manager pages window.ga is truthy but not callable, so with analytics: true the first volumechange/play throws an uncaught TypeError: window.ga is not a function and stalls whatever the host page chained after CldVideoPlayer init (we saw this take down an unrelated gallery widget on a customer site). The analytics plugin was rewritten around gtag in later majors, so the fix is to load a current player.

Changes

• PLAYER_VERSION → 4.1.2 in CldVideoPlayer.tsx and plugins/copy-assets.ts.
• @cloudinary-util/url-loader 5.10.4 → 6.3.2 (+ types 1.7.0, util 4.3.0, which 6.3.2 depends on). 5.10.4 derives aspectRatio: "w:h" from width/height, which breaks poster URLs on player v4 (Supplying an aspect ratio AND the transformation parameter causes poster URLs to fail cloudinary/cloudinary-video-player#1087). 6.3.2 removed that specifically to unblock the v4 upgrade (cloudinary-community/cloudinary-util@c595c99). All url-loader/util/types symbols this package imports still exist in the new versions.
• Drop the icon-font download from copy-assets.ts. dist/fonts/*.svg does not exist on unpkg for 1.11.1 or 4.1.2 (the icons are inlined in the CSS), so the build has been writing unpkg's 404 HTML body into dist/fonts/*.svg for a long time — that's what next-cloudinary@6.19.3 ships today. Nothing in this repo or the docs references dist/fonts. With only one asset left, the loop's string/directory branches were dead and got flattened.

Compatibility notes (1.11.1 → 4.1.2)

• dist/cld-video-player.min.js is kept in v4 as the full, synchronous bundle (alias of player-full.min.js), so cloudinary.videoPlayer() still returns a real VideoPlayer instance immediately; player.on() and player.videojs.cloudinary.dispose() — everything CldVideoPlayer.tsx touches — are unchanged.
• dist/cld-video-player.min.css still exists at the same path.
• Verified against the player source that every option key getVideoPlayerOptions() emits (cloud_name, privateCdn, secureDistribution, publicId, transformation, posterOptions, showLogo/logoImageUrl/logoOnclickUrl, autoplayMode, sourceTypes, …) is still accepted by 4.x, and that the [{ quality: "auto" }, undefined] transformation array url-loader produces when no transformation prop is set builds correct source/poster URLs on 4.1.2.

Test plan

• pnpm build — succeeds; dist/cld-video-player.css is the v4.1.2 stylesheet, no dist/fonts
• pnpm test — 16/16 pass
• tests/nextjs-app (Next 16 / React 19) npm run build against the rebuilt package — succeeds
• Manual: render <CldVideoPlayer width="1620" height="1080" src="…" /> with and without analytics: true on a page that loads gtag.js; confirm playback, poster, and no console errors — I can't verify visually from here, so a maintainer sanity check in the browser would be appreciated

Related: cloudinary/cloudinary-video-player#1092 hardens the same call site in the current player's gtag path.

🤖 Generated with Claude Code

[vercel]

@adim-blip is attempting to deploy a commit to the Cloudinary DevX Team on Vercel.

A member of the Team first needs to authorize it.

[eportis-cloudinary]

Thank you so much for this contribution!

The url-loader upgrade (and to a lesser extent the player library update) are potentially breaking changes. I've implemented this particular change in #665 and we are going to batch it up with a bunch of other changes which should get released in a new major version (7.0, tracked in #523) within the next couple of weeks.

If you need this functionality now, it should land in the beta channel after #665 is reviewed by @PaulBoye-py sometime in the next few days.