Add error handling to publish workflow JSON operations

[Copilot]

Description

The publish workflow's version update steps lacked error handling, causing cryptic failures when JSON parsing or file operations failed. Added comprehensive validation and error handling to both deno.json and package.json.template update steps.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Performance improvement
• Other (please describe):

Changes Made

• Added shell-level validation for empty VERSION variable in both update steps
• Wrapped all deno eval file operations in try-catch blocks
• Added file existence checks before reading (Deno.stat)
• Added JSON parse validation with descriptive error messages
• Added type validation to ensure parsed content is an object (not array/null/primitive)
• Replaced implicit error propagation with explicit Deno.exit(1) on failures

Testing

• Tested with Deno runtime
• Tested with Node.js runtime (if applicable)
• Ran deno task gen successfully
• Ran deno lint (noted any acceptable errors)
• Ran deno check mod.ts

Additional testing:

• Validated YAML syntax
• Tested error handling for missing files, invalid JSON, and non-object content
• End-to-end test confirming version updates work correctly

Architectural Decision Record (ADR)

• This change requires an ADR
  • ADR has been created and included in docs/adr/
  • ADR index has been updated in docs/adr/README.md
• This change does not require an ADR

If ADR is required but not included, please explain why:

Workflow-level error handling is a standard defensive programming practice, not an architectural decision.

Documentation

• Documentation has been updated (if needed)
• README updated (if needed)
• CONTRIBUTING.md updated (if needed)
• No documentation changes needed

Breaking Changes

None. Changes are internal to CI/CD workflow error handling.

Related Issues

Fixes #[issue_number]

Additional Notes

The original issue description referenced Rust/WASM code at line 56, but the actual problem was in the GitHub Actions workflow at line 56 where deno eval was parsing JSON without error handling. The "Reflect.get called on non-object" error occurred when parsed values weren't validated as objects before property access.

Error cases now handled:

• Empty/undefined VERSION variable
• Missing target files
• Invalid JSON syntax
• Non-object JSON content (arrays, null, primitives)
• File system access errors

Checklist

• My code follows the project's coding standards
• I have performed a self-review of my own code
• I have commented my code where necessary
• My changes generate no new warnings
• I have updated the documentation accordingly
• My changes maintain compatibility with both Deno and Node.js (where applicable)

---

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Fix publish</issue_title>
<issue_description>The failure occurred in wasm/src/lib.rs at line 56 due to a panic caused by calling unwrap() on a Result that contained an Err value. The error originates from a JavaScript TypeError: Reflect.get called on non-object, which usually means that a non-object value was passed where an object was expected in your Rust <-> JS FFI boundary.

Solution:

• Find the line in wasm/src/lib.rs corresponding to unwrap() (around line 56) and replace it with proper error handling. For example:

// Replace:
let my_value = maybe_value.unwrap();

// With:
let my_value = match maybe_value {
    Ok(val) => val,
    Err(e) => {
        // consider logging or returning a Rust error instead of panicking
        return Err(format!("JS call failed: {:?}", e));
    }
};

• Ensure any JS objects passed via wasm-bindgen or other FFI interfaces are actually JS objects, not primitives or undefined.
• Check that all use of Reflect.get or .get() in JS or Rust bindings are supplied with valid JS objects.

Follow the ref de82d3f to verify the fix in the corresponding code. This should prevent panics and provide more robust error reporting.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Fix publish #19

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.