fix: avoid Buffer in imgproxy provider

[AlejandroAkbal]

Summary

• replace the imgproxy provider's Node Buffer usage with browser-safe TextEncoder + btoa
• keep the same URL-safe base64 output shape without adding new dependencies
• fix client/browser builds that fail when Vite externalizes buffer

Summary by CodeRabbit

• Bug Fixes
  • Enhanced browser compatibility for image encoding in the image proxy provider, ensuring more reliable image processing in web environments.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 64e3088e-6ead-42f4-abaf-4beab6184c61

📥 Commits

Reviewing files that changed from the base of the PR and between 48a3a10 and 2dcd35d.

📒 Files selected for processing (1)

• assets/js/nuxt-image/imgproxy.provider.ts

📜 Recent review details

🔇 Additional comments (1)

assets/js/nuxt-image/imgproxy.provider.ts (1)

40-43: Buffer removal is correctly implemented with equivalent URL-safe output.

This preserves the UTF-8 → base64 flow and keeps the existing URL-safe transformation behavior while unblocking browser builds.

---

📝 Walkthrough

Walkthrough

The implementation of base64 encoding in the image proxy provider was refactored to use browser-native APIs instead of Node.js Buffer, improving cross-environment compatibility. The urlSafeBase64 function now uses TextEncoder and btoa for encoding while maintaining the existing URL-safe base64 transformation logic.

Changes

Cohort / File(s)	Summary
Image Proxy Encoding assets/js/nuxt-image/imgproxy.provider.ts	Replaced Node.js Buffer-based UTF-8 to base64 encoding with browser-compatible implementation using TextEncoder and btoa APIs. Removed buffer dependency and updated internal encoding logic while preserving URL-safe base64 post-processing (padding removal and character translation).

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title clearly and concisely describes the main change: replacing Buffer usage in the imgproxy provider with a browser-compatible approach.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/imgproxy-browser-buffer

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch fix/imgproxy-browser-buffer

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[AlejandroAkbal]

@copilot is this completely safe to integrate? no edge cases/

[Copilot]

@AlejandroAkbal I've opened a new pull request, #116, to work on those changes. Once the pull request is ready, I'll request review from you.

[AlejandroAkbal]

@coderabbitai is this PR safe to merge? there is no hard change, breaking change or anything related?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

Let me read the file to verify the implementation details before giving you a confident answer.

---

🏁 Script executed:

#!/bin/bash
fd "imgproxy.provider.ts" --exec cat {}

Length of output: 2322

---

@AlejandroAkbal Yes, this PR is safe to merge. Here's a breakdown of why:

---

✅ Functional Equivalence

The new urlSafeBase64 implementation is bit-for-bit equivalent to the old Buffer-based one:

Step	Old (Buffer)	New (TextEncoder + btoa)
String → UTF-8 bytes	Buffer.from(string)	new TextEncoder().encode(string)
Bytes → base64	.toString('base64')	binary string → btoa()
URL-safe post-process	.replace(...)	.replace(...) (identical)

Both use UTF-8 encoding by default, so the output is identical for any input.

---

✅ No Breaking Changes

• No exported or public function signatures were changed.
• The urlSafeBase64 function is purely internal.
• The generated imgproxy URLs will be identical to before, so existing cached URLs remain valid.

---

✅ Browser & Runtime Compatibility

• TextEncoder: available in all modern browsers (Chrome 38+, Firefox 18+, Safari 10.1+) and Node.js 11+.
• btoa: universally available in browsers and Node.js 16+.
• String.fromCodePoint: ES2015, widely supported.
• UTF-8 bytes are always in range 0–255, so btoa (which only accepts Latin-1) will never throw.

---

✅ Edge Cases — All Clear

• Empty string → btoa('') → '' — works fine.
• ASCII URLs → same output as before.
• Non-ASCII/Unicode in URLs → both old and new approaches encode to UTF-8 bytes first, so output is identical.
• SSR (Nuxt server-side) → TextEncoder is natively available in Node.js, so no issues there either.

---

Bottom line: This is a pure browser-compatibility fix with no behavioral change. Safe to merge. 🟢