deps(deps-dev): bump @exodus/bytes from 1.14.1 to 1.15.0

[dependabot]

Bumps @exodus/bytes from 1.14.1 to 1.15.0.

Release notes

Sourced from @​exodus/bytes's releases.

v1.15.0

• feat: isomorphicDecode(), isomorphicEncode() in /encoding.js (in ExodusOSS/bytes#68)
• doc: deprecate latin1toString() / latin1fromString() in favor of isomorphicDecode() / isomorphicEncode() (see ExodusOSS/bytes#55)
• feat: fromBase32crockford / toBase32crockford in /base32.js
• feat: typedCopyBytes() in /array.js
• feat: add 'arraybuffer' output format support in methods accepting format parameter (in ExodusOSS/bytes#70)
• feat: 'uint8' (default) output format now never returns pooled Uint8Array instances (see below)

This release brings support of native ArrayBuffer return format (under the name of format: 'arraybuffer').

Converting Uint8Array to ArrayBuffer downstream is non-trivial, and there is a lot of confusion in the ecosystem around those. A simple access to .buffer is often seen and is incorrect -- code accepting Uint8Arrays that it didn't create should not assume that it did not receive for example a result of .subarray() (where .buffer size mismatches the view size), or a Node.js pooled Buffer instance (which are also Uint8Arrays).

That pattern (using .buffer and failing to check bounds) has been a source of numerous errors in ecosystem libraries.

To minimize the risks from such mistakes, this library now never returns Uint8Array instances (default format) that are not complete views of their underlying ArrayBuffer.

In other words, now the following are true for a returned Uint8Array instance u8:

• u8.buffer.byteLength === u8.byteLength
• u8.byteOffset === 0
• deepStrictEqual(new Uint8Array(u8.buffer), u8)

The affected parts (which previously returned non-complete views / subarrays) are:

1. On multiple platforms: fromBase58Check, createMultibyteEncoder, createSinglebyteEncoder
2. On Node.js import condition only (any Node.js version): latin1fromString, utf8fromString, utf16fromString
3. On Node.js import condition with Node.js < 25: fromHex, fromBase64

This comes at a reasonable performance cost (almost exclusively on Node.js import condition), but correctness/security comes first.

[!NOTE] This change doesn't affect TextEncoder, which is already governed by the Encoding Standard which demands non-pooled Uint8Arrays.

This also doesn't affect typedView() (from /array.js) which by definition is always a view of the same underlying ArrayBuffer data. But now typedCopyBytes() is introduced.

[!IMPORTANT] This change does not affect 'buffer' return format, which can still return pooled Buffer instances. This is similar to the behavior of native Buffer.from / Buffer.alloc which are pooled.

Apart from making returned Uint8Array instances complete views, a dedicated ArrayBuffer return format is introduced to eliminate the need to use .buffer on the returned values in downstream code at all (as it's a bad pattern in general and tooling/lint will/should flag that).

Full Changelog: ExodusOSS/bytes@v1.14.1...v1.15.0

Commits

• e20c47f v1.15.0
• c907ea8 feat: add ArrayBuffer output support (#70)
• dbf7398 fix: improve base32/base64 types for format: 'buffer'
• 93472b6 doc: add documentation link badge
• 5ca0f41 feat: typedCopyBytes
• 8d54290 refactor: prefer fromBuffer in hex.node, allow pooled Buffer
• f8111ad feat: fromBase64 never returns pooled Uint8Arrays
• 6034e9c feat: utf16fromString never returns pooled TypedArrays
• 2ef8f54 feat: utf8fromString never returns pooled Uint8Arrays
• fa1a81f fix: multi-byte encoder on ASCII does not return pooled Uint8Arrays on Hermes
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[github-actions]

🚀 Preview deployed!

Your changes are now available at: https://commjoen.github.io/generated-game-experiment/pr-393/

This preview will be automatically cleaned up when the PR is closed or merged.

[github-actions]

🐳 Docker Image Built Successfully!

Image: ghcr.io/commjoen/generated-game-experiment:pr-393

🚀 Quick Test

# Pull and run the PR image
docker pull ghcr.io/commjoen/generated-game-experiment:pr-393
docker run -p 8080:80 -p 3001:3001 ghcr.io/commjoen/generated-game-experiment:pr-393

# Access the game
open http://localhost:8080

📋 Features Tested

• ✅ Game client loads on port 80
• ✅ Multiplayer server starts on port 3001
• ✅ Health checks pass
• ✅ Multi-platform build (amd64, arm64)

🔗 Container Details

• Registry: GitHub Container Registry (ghcr.io)
• Platforms: linux/amd64, linux/arm64
• Size: Optimized multi-stage build
• Security: Runs as non-root user

🌐 Deploy to Render

You can deploy this specific image to Render by updating the image reference in your service settings.

[github-actions]

🧹 Preview cleaned up!

The preview deployment for this PR has been automatically removed from GitHub Pages.