Fix Reflect.get panic in parser.ts during npm build

[Copilot]

Description

The publish workflow fails with TypeError: Reflect.get called on non-object when dnt's WASM transformer processes src/parser.ts. The code was accessing Deno.cwd() through (globalThis as any).Deno.cwd(), which triggers unsafe Reflect operations during build.

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

• src/parser.ts:95-96: Replace (globalThis as any).Deno.cwd() with direct Deno.cwd() access after isDeno check
• Add comment explaining safety of direct access post-check

Before:

if (isDeno) {
  importPath = `${(globalThis as any).Deno.cwd()}/${importPath}`;
}

After:

if (isDeno) {
  // Safe to access Deno directly after checking isDeno
  importPath = `${Deno.cwd()}/${importPath}`;
}

This aligns with patterns in runtime.ts and cli.ts where isDeno check uses "Deno" in globalThis, then accesses Deno directly without globalThis indirection.

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

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

Documentation

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

Breaking Changes

None.

Related Issues

Fixes publish workflow panic during npm package build.

Additional Notes

The "Deno" in globalThis pattern safely checks for Deno's existence without triggering Reflect.get. Once confirmed, accessing Deno directly from global scope avoids WASM transformer issues.

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 job failed due to a panic in wasm/src/lib.rs at line 56, where Result::unwrap() was called on an Err value. The error message is: TypeError: Reflect.get called on non-object, indicating an issue with JavaScript interop—most likely the Rust code is attempting to use Reflect.get on something that isn't a JS object.

Solution:

• Replace unwrap() with proper error handling at wasm/src/lib.rs:56 to avoid panics. Use pattern matching (e.g., match or if let) to handle the Err case gracefully and log or report it rather than crashing.
• Ensure that any object passed to Reflect.get in your JS glue code is a valid JavaScript object.

Example code adjustment:

// Example of handling the Result without unwrap()
match some_result {
    Ok(val) => { /* normal processing */ },
    Err(err) => {
        // handle or report the error instead of panicking
        eprintln!("JS interop error: {:?}", err);
        return Err(err.into());
    }
}

Check the type of any JSValue you interact with before using Reflect.get to ensure it's an object.

You can find the failing line here (on ref de82d3f):
wasm/src/lib.rs

By implementing these adjustments, you can prevent panics and properly handle JS interop errors.</issue_description>

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

• Fixes fix publish #21

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.