fix(parsePath): not throwing error when package

[aka-sacci-ccr]

Summary by CodeRabbit

• Bug Fixes
  • Improved file path resolution to properly handle unresolvable file paths. The system now returns early with a diagnostic warning instead of attempting to process invalid references, reducing downstream errors and improving error visibility for debugging.

[github-actions]

Tagging Options

Should a new tag be published when this PR is merged?

• 👍 for Patch 1.128.3 update
• 🎉 for Minor 1.129.0 update
• 🚀 for Major 2.0.0 update

[coderabbitai]

Walkthrough

The parsePath function in the schema parser now returns undefined early when a file-prefixed path fails to resolve an extension and lacks a recognized extension natively, emitting a console warning instead of attempting to load the unresolved path.

Changes

Cohort / File(s)	Summary
File path resolution guard engine/schema/parser.ts	Added early return in parsePath when file extension resolution fails for file: URIs lacking recognized extensions; emits console warning and returns undefined instead of continuing with unresolved path

Sequence Diagram(s)

sequenceDiagram
    participant Caller
    participant parsePath
    participant resolveFileExtension

    rect rgb(200, 220, 240)
    Note over parsePath: Old Flow
    Caller->>parsePath: parsePath(filePath)
    alt path starts with "file:"
        parsePath->>resolveFileExtension: resolve extension
        resolveFileExtension-->>parsePath: unresolved
        parsePath->>parsePath: continue with unresolved path<br/>(potential errors)
    end
    parsePath-->>Caller: result or error
    end

    rect rgb(220, 240, 220)
    Note over parsePath: New Flow
    Caller->>parsePath: parsePath(filePath)
    alt path starts with "file:"
        parsePath->>resolveFileExtension: resolve extension
        resolveFileExtension-->>parsePath: unresolved
        alt no recognized extension
            parsePath->>parsePath: console.warn()
            parsePath-->>Caller: undefined
        else has extension
            parsePath->>parsePath: proceed as before
        end
    end
    end

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

• Key focus areas:
  • Verify the early return condition logic is correct and doesn't skip valid paths
  • Confirm console warning message is appropriate and helpful for debugging
  • Ensure the change doesn't break existing callers expecting different behavior from unresolved paths

Poem

A rabbit hops through paths so long,
Now checking extensions—stays strong!
When file: calls without a name,
Early return tames the game. 🐰✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Title Check	❓ Inconclusive	The pull request title "fix(parsePath): not throwing error when package" is partially related to the changeset but suffers from vagueness and appears to be incomplete. The title correctly identifies the function being modified (parsePath) and references error handling behavior, which aligns with the change of returning undefined and emitting a warning instead of proceeding with an unresolvable path. However, the phrase "when package" seems truncated, and the overall description doesn't clearly convey what specific scenario the fix addresses—namely, handling the failure of file extension resolution for file-prefixed paths. A developer scanning the history would struggle to understand the precise nature of the fix from this title alone.	The title should be more complete and specific. Consider revising it to clearly describe the problem being fixed, such as "fix(parsePath): handle missing file extension gracefully for file: paths" or similar phrasing that explains what scenario is being addressed and how the fix improves the behavior.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/parsePath

---

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)

engine/schema/parser.ts (1)

303-310: Consider extracting the duplicated extension regex pattern.

The regex pattern /\.(ts|tsx|js|jsx|mjs|cjs|d\.ts|d\.mts|d\.cts)$/ is duplicated from line 65. Consider extracting it to a named constant at the module level to improve maintainability and ensure consistency if the list of supported extensions ever changes.

For example, add near the top of the file:

+const KNOWN_EXTENSIONS_REGEX = /\.(ts|tsx|js|jsx|mjs|cjs|d\.ts|d\.mts|d\.cts)$/;
+
 const JS_REGEX_PATH: RegExp = /\.(m?js|cjs)$/;

Then update both occurrences:

 // In resolveFileExtension (line 65)
-  if (pathStr.match(/\.(ts|tsx|js|jsx|mjs|cjs|d\.ts|d\.mts|d\.cts)$/)) {
+  if (pathStr.match(KNOWN_EXTENSIONS_REGEX)) {
     return filePath;
   }

 // In parsePath (line 303)
-  } else if (!path.match(/\.(ts|tsx|js|jsx|mjs|cjs|d\.ts|d\.mts|d\.cts)$/)) {
+  } else if (!path.match(KNOWN_EXTENSIONS_REGEX)) {
     // If resolution failed and path has no extension, return undefined instead of throwing

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 63c3498 and 7da3e01.

📒 Files selected for processing (1)

• engine/schema/parser.ts (1 hunks)

🔇 Additional comments (1)

engine/schema/parser.ts (1)

303-310: Good improvement: graceful handling of unresolvable paths.

This change appropriately handles the case where a file path cannot be resolved and lacks a recognized extension. Returning undefined early with a warning is consistent with the npm package handling pattern (lines 289-294) and prevents unnecessary attempts to load non-existent files that would fail later at line 317.

The warning message provides helpful debugging information while avoiding exceptions for paths that cannot be resolved.