One gotcha with JS errors: their default stringification method only grabs the error's name and message properties – the entire stack gets lost (partially because stack technically is a non-standard property, even though it's basically added everywhere)

I would go for something like this:

throw new Error(
  `agentResource encode failed, missing defaults?\n${e}\n${e.stack ?? ""}`
);

I was looking to avoid the double stack trace (hence discarding the original one since we still create one at new Error), but I agree that the original stack can also be useful, I'll make the change 👍🏻

Oh, wait – forgot there's one other issue. Since JS/TS allow you to throw any kind of value at all, TS doesn't assume that a thrown value is actually an error, and just defaults to type unknown

You'd need a type guard to prove to the compiler that the value is an error before you try accessing error-specific properties from it

try {
  // Throw-able code
} catch (e) {
  let errorMessage  = `agentResource encode failed, missing defaults?\n${e}`;
  if (e instanceof Error) {
    errorMessage += `\n${e.stack}`;
  }
   
  throw new Error(errorMessage);
}

Obviously, because JS, the ${e.name}: ${e.message} is sometimes included in the stack trace (Node, etc.) and other times not (browser). Hopefully we now have a satisfying solution with the last commit. 😄