fix(types): add missing code property to Deno.errors.NotFoundfix(types): add missing code property to Deno.errors.NotFound

[VISHNU7KASIREDDY]

Description

This PR adds the missing code property to the Deno.errors.NotFound type definition.

Problem

The NotFound error class has a code property at runtime (typically 'ENOENT'), but this property was missing from the TypeScript type definition. This caused TypeScript errors when developers tried to access the code property.

Example from issue #22807:

try {
  Deno.readTextFileSync("doesnt-exist");
} catch (e) {
  console.log((e as Deno.errors.NotFound).code); // TypeScript error!
}

Solution

Added code: string property to the Deno.errors.NotFound class definition in cli/tsc/dts/lib.deno.ns.d.ts.

Changes

• Added code: string property to Deno.errors.NotFound class
• Created test file to demonstrate the fix

Testing

This is a type-only change that adds the missing property to match runtime behavior. The change enables TypeScript to correctly type-check code that accesses the code property on NotFound errors.

Fixes #22807The NotFound error class has a code property at runtime (typically 'ENOENT'), but this property was missing from the TypeScript type definition. This caused TypeScript errors when developers tried to access the code property.

This change adds the code property to the type definition to match the runtime behavior and provide proper type safety.

Fixes #22807

[coderabbitai]

Walkthrough

The type declaration for Deno.errors.NotFound in cli/tsc/dts/lib.deno.ns.d.ts was changed to include a code: string property. A new test test_error_code.ts was added that reads a non-existent file, catches the error, checks instanceof Deno.errors.NotFound, and logs the error code and message.

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: adding the missing code property to Deno.errors.NotFound type definition.
Description check	✅ Passed	The description is well-structured, explaining the problem, solution, and changes. It directly addresses the missing code property on the NotFound type.
Linked Issues check	✅ Passed	The PR directly addresses issue #22807 by adding the missing code property to Deno.errors.NotFound type definition, matching runtime behavior.
Out of Scope Changes check	✅ Passed	All changes are within scope: the type definition update and test file both directly support fixing the missing code property issue.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between cc99e12 and fa030e3.

📒 Files selected for processing (1)

• cli/tsc/dts/lib.deno.ns.d.ts (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• cli/tsc/dts/lib.deno.ns.d.ts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

test_error_code.ts (1)

1-12: Consider making this a proper test with assertions.

This file demonstrates that e.code is type-checkable, but it doesn't verify the runtime behavior. Consider using the Deno test framework and adding assertions:

-// Test file to verify the code property is accessible on Deno.errors.NotFound
-try {
-  Deno.readTextFileSync("doesnt-exist");
-} catch (e) {
-  if (e instanceof Deno.errors.NotFound) {
-    // This should now compile without TypeScript errors
-    console.log("Error code:", e.code);
-    console.log("Error message:", e.message);
-  } else {
-    throw e;
-  }
-}
+import { assertEquals, assertInstanceOf } from "jsr:@std/assert";
+
+Deno.test("NotFound error has code property", () => {
+  try {
+    Deno.readTextFileSync("doesnt-exist");
+  } catch (e) {
+    assertInstanceOf(e, Deno.errors.NotFound);
+    assertEquals(e.code, "ENOENT");
+  }
+});

This ensures the code property exists, is accessible, and has the expected value at runtime.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5b2dc85 and cc99e12.

📒 Files selected for processing (2)

• cli/tsc/dts/lib.deno.ns.d.ts (1 hunks)
• test_error_code.ts (1 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**/*.{ts,tsx,js}

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.{ts,tsx,js}: For JavaScript runtime debugging, enable V8 inspector with --inspect-brk flag and connect Chrome DevTools to chrome://inspect
Use console.log() for debug prints in JavaScript runtime code

Files:

• cli/tsc/dts/lib.deno.ns.d.ts
• test_error_code.ts

🔇 Additional comments (1)

cli/tsc/dts/lib.deno.ns.d.ts (1)

174-176: Reconsider adding code property to other Deno error classes—it may not align with Deno's error handling approach.

Based on Deno's official documentation, the built-in error classes (Deno.errors.NotFound, Deno.errors.PermissionDenied, Deno.errors.ConnectionRefused, etc.) do not expose a code property at runtime. Deno's error handling pattern relies on instanceof checks rather than the Node.js-style error.code property (e.g., "ENOENT", "EACCES").

Before adding code: string to other error classes, verify whether NotFound actually has this property at runtime or if this is intended as a compatibility/interop layer specific to this PR. If it is runtime behavior, document that context in the PR. If this is an intentional compatibility addition for this PR alone, adding code to other errors without the same justification would be inconsistent.

If code is being added for Node.js compatibility, consider documenting the rationale and scope. The readonly suggestion remains reasonable if the property is immutable at runtime.

[VISHNU7KASIREDDY]

@JJ @fd @mocoso please review this when you are free,thank you

[VISHNU7KASIREDDY]

@nathanwhit please review this when you are free ,Thank You.