Make errors stack traces of createPacketBuffer readable

[zardoy]

Some error reporting tools like Sentry already do increase stack trace limit, but I think it would be good to make this default behavior. example stack trace with the extended limit:

at module.exports.Write.UUID (minecraft-protocol@1.47.0\node_modules\minecraft-protocol\src\datatypes\compiler-minecraft.js:48:25)    
    at eval (eval at compile (protodef@1.15.0\node_modules\protodef\src\compiler.js:258:12), <anonymous>:1909:30)
    at eval (eval at compile (protodef@1.15.0\node_modules\protodef\src\compiler.js:258:12), <anonymous>:2395:11)
    at Object.packet_player_info (eval at compile (protodef@1.15.0\node_modules\protodef\src\compiler.js:258:12), <anonymous>:2398:9)     
    at eval (eval at compile (protodef@1.15.0\node_modules\protodef\src\compiler.js:258:12), <anonymous>:3375:62)
    at packet (eval at compile (protodef@1.15.0\node_modules\protodef\src\compiler.js:258:12), <anonymous>:3430:9)
    at CompiledProtodef.write (protodef@1.15.0\node_modules\protodef\src\compiler.js:76:12)
    at protodef@1.15.0\node_modules\protodef\src\compiler.js:102:25
    at tryCatch (protodef@1.15.0\node_modules\protodef\src\utils.js:51:16)
    at CompiledProtodef.createPacketBuffer (protodef@1.15.0\node_modules\protodef\src\compiler.js:102:5)
    at Serializer.createPacketBuffer (protodef@1.15.0\node_modules\protodef\src\serializer.js:12:23)
    at Serializer._transform (protodef@1.15.0\node_modules\protodef\src\serializer.js:18:18)
    at Transform._read (readable-stream@3.6.2\node_modules\readable-stream\lib\_stream_transform.js:166:10)
    at Transform._write (readable-stream@3.6.2\node_modules\readable-stream\lib\_stream_transform.js:155:83)
    at doWrite (readable-stream@3.6.2\node_modules\readable-stream\lib\_stream_writable.js:390:139)
    at writeOrBuffer (readable-stream@3.6.2\node_modules\readable-stream\lib\_stream_writable.js:381:5)
    at Writable.write (readable-stream@3.6.2\node_modules\readable-stream\lib\_stream_writable.js:302:11)
    at Client.write (minecraft-protocol@1.47.0\node_modules\minecraft-protocol\src\client.js:241:21)
(18)at sendLoginPacket (main.ts:200:20)

If you don't like the idea of increasing the stack trace consider at least adding the packet to the message that caused the problem

[rom1504]

Please provide some examples of errors with the new code

The TryCatch part applies to lot of places

[zardoy]

Please provide some examples of errors with the new code

The TryCatch part applies to lot of places

@rom1504
In minecraft protocol, with incorrect package writes we get error stacks like this:

August 14 2025, 02:40:16 [ERROR]: Client ::1:58629 : RangeError [ERR_OUT_OF_RANGE]: Write error for undefined : The value of "value" is out of range. It must be >= -128 and <= 127. Received 174.375
    at writeU_Int8 (node:internal/buffer:740:11)
    at Buffer.writeInt8 (node:internal/buffer:871:10)
    at Object.writer [as i8] (/Users/vit/Documents/testing-minecraft-protocol/node_modules/protodef/src/datatypes/numeric.js:97:25)
    at Object.packet_named_entity_spawn (eval at compile (/Users/vit/Documents/testing-minecraft-protocol/node_modules/protodef/src/compiler.js:262:12), <anonymous>:657:24)
    at eval (eval at compile (/Users/vit/Documents/testing-minecraft-protocol/node_modules/protodef/src/compiler.js:262:12), <anonymous>:2509:76)
    at packet (eval at compile (/Users/vit/Documents/testing-minecraft-protocol/node_modules/protodef/src/compiler.js:262:12), <anonymous>:2611:9)
    at CompiledProtodef.write (/Users/vit/Documents/testing-minecraft-protocol/node_modules/protodef/src/compiler.js:76:12)
    at e.message (/Users/vit/Documents/testing-minecraft-protocol/node_modules/protodef/src/compiler.js:102:25)
    at tryCatch (/Users/vit/Documents/testing-minecraft-protocol/node_modules/protodef/src/utils.js:50:16)
    at CompiledProtodef.createPacketBuffer (/Users/vit/Documents/testing-minecraft-protocol/node_modules/protodef/src/compiler.js:102:5)
    at Serializer.createPacketBuffer (/Users/vit/Documents/testing-minecraft-protocol/node_modules/protodef/src/serializer.js:12:23)
    at Serializer._transform (/Users/vit/Documents/testing-minecraft-protocol/node_modules/protodef/src/serializer.js:18:18)
    at Transform._write (/Users/vit/Documents/testing-minecraft-protocol/node_modules/readable-stream/lib/internal/streams/transform.js:153:8)
...

these are not useful, however if it could also log the packet at the same time, the issue would become very obvious:

{
  entityId: 3,
  playerUUID: "dda915f8-abf6-31e8-8221-e0eaa1f9c4c7",
  x: 1.9803428762649924,
  y: 1,
  z: 3.1427253741851437,
  yaw: 174.375, // thats the value
  pitch: 33.75,
  currentItem: 0,
  metadata: [
    {
      key: 0,
      type: 0,
      value: 0,
    },
  ],
}

please consider this, IMO its better rather than not providing any additional info (right now there is no way to get the packet from the exception at all)

[rom1504]

Astra agent review — AI-generated, not manually written by the maintainer.

The examples now explain why additional diagnostics help, so the earlier request for examples is answered. The remaining decision is scope: tryCatch is shared by codecs, and changing global Error.stackTraceLimit around every invocation affects the whole synchronous call tree; unconditional packet serialization also changes error-message size and exposes complete packet contents to logging.

Prefer an explicit diagnostic option or a narrowly owned error path, with bounded packet context. Coordinate actual compiled field paths with #180 so useful location information does not depend on logging an entire value. This is a design/maintenance assessment, not a measured performance regression; no benchmark or fresh suite was run.

Skills used: prismarine-review checked the unchanged diff and current discussion; prismarine-architecture-review traced the public API, ownership and failure behavior.