Skip to content

feat: merge from upstream oxc-project/oxc-resolver - 8th#178

Merged
JounQin merged 11 commits intomainfrom
chore/merge_upstream
Jul 6, 2025
Merged

feat: merge from upstream oxc-project/oxc-resolver - 8th#178
JounQin merged 11 commits intomainfrom
chore/merge_upstream

Conversation

@JounQin
Copy link
Member

@JounQin JounQin commented Jul 6, 2025

Important

Merge upstream changes from oxc-project/oxc-resolver, adding Yarn PnP support, refactoring caching, and updating tests.

  • New Features:
    • Added support for specifying the current working directory in resolution options.
    • Improved Yarn Plug'n'Play (PnP) integration, including automatic detection and environment variable support.
    • Enhanced documentation with a new section on Yarn Plug'n'Play usage.
  • Bug Fixes:
    • Improved error handling for Yarn Plug'n'Play manifest resolution.
  • Refactor:
    • Replaced trait-based abstractions for caching, package.json, and tsconfig handling with concrete, Serde-based structs and methods.
    • Unified and simplified resolver, cache, and file system abstractions for better performance and clarity.
    • Generalized dependency versions and simplified feature flags in configuration files.
  • Chores:
    • Updated CI workflow and test scripts for streamlined testing and build processes.
    • Adjusted formatting and configuration files for consistency.
  • Tests:
    • Added and updated tests to cover new PnP features and refactored code paths.

This description was created by Ellipsis for e7744de. You can customize this summary. It will automatically update as commits are pushed.


Summary by CodeRabbit

  • New Features

    • Added support for specifying the current working directory in resolution options.
    • Improved Yarn Plug'n'Play (PnP) integration, including automatic detection and environment variable support.
    • Enhanced documentation with a new section on Yarn Plug'n'Play usage.
  • Bug Fixes

    • Improved error handling for Yarn Plug'n'Play manifest resolution.
  • Refactor

    • Replaced trait-based abstractions for caching, package.json, and tsconfig handling with concrete, Serde-based structs and methods.
    • Unified and simplified resolver, cache, and file system abstractions for better performance and clarity.
    • Generalized dependency versions and simplified feature flags in configuration files.
  • Chores

    • Updated CI workflow and test scripts for streamlined testing and build processes.
    • Adjusted formatting and configuration files for consistency.
  • Tests

    • Added and updated tests to cover new PnP features and refactored code paths.

Boshen and others added 9 commits July 4, 2025 13:54
The current manifest file (`.pnp.cjs`) lookup technique does not work
when `enableGlobalCache` is set to `true`, which is the default behavior
for yarn.

Instead, we try and find the closest pnp maniest from cwd.

This will break the multi-project case mentioned in
https://yarnpkg.com/advanced/pnp-spec#find_pnp_manifest, but I think
this is an acceptable trade off.

For napi, I set `process.env.OXC_RESOLVER_YARN_PNP` in `napi/index.js`
so the Rust side can enable yarn pnp accordingly.
This feature was added for Biome. Biome no longer uses oxc-resolver.
Remove it to simplify the codebase.
Running fs operations through yarn pnp incurs significant performance
cost, caused by running `VPath::from(path)` on every path.

Feature gate this through a runtime flag,
because a bundler can enable `yarn_pnp` feature but run the resolver
without presence of `yarn`.
@JounQin JounQin requested a review from Copilot July 6, 2025 11:58
@JounQin JounQin self-assigned this Jul 6, 2025
@JounQin JounQin added the upstream Blocked by upstream label Jul 6, 2025
@coderabbitai
Copy link

coderabbitai bot commented Jul 6, 2025

Walkthrough

This update removes trait-based abstractions for caching, package.json, and tsconfig handling, replacing them with concrete, Serde-deserializable structs and a unified, generic Cache implementation. The fs_cache, package_json_serde, and tsconfig_serde modules are deleted. Yarn Plug'n'Play (PnP) support is refactored and enabled by default via environment variable. Test and CI workflows are updated accordingly.

Changes

Files/Paths Change Summary
.github/workflows/ci.yml, justfile, README.md, .prettierrc, deny.toml, release-plz.toml CI updated to use just test; test/build scripts consolidated; Prettier config line width set; license allow-list reordered; release semantic version check disabled; README documents Yarn PnP usage.
Cargo.toml, napi/Cargo.toml Dependency versions generalized; features simplified; Yarn PnP feature enabled by default in napi crate; fs_cache dependencies removed.
fixtures/pnp/index.test.mjs, fixtures/pnp/package.json New test and script added to verify resolver matches Yarn PnP API resolution.
napi/index.d.ts, napi/index.js, napi/patch.mjs, napi/src/lib.rs, napi/src/options.rs yarnPnp option removed from API; environment variable detection for Yarn PnP added; napi Rust bindings refactored to match new options; internal option handling simplified.
src/cache.rs Entirely rewritten: trait-based cache replaced by concrete, generic, thread-aware Cache<Fs> struct and CachedPath type, supporting path, package.json, tsconfig, and optional Yarn PnP manifest caching.
src/error.rs New error variants for Yarn PnP; serde_json error method always enabled.
src/file_system.rs FileSystem trait and FileSystemOs updated with runtime Yarn PnP flag and new constructors; methods dispatch on feature and runtime flag.
src/fs_cache.rs, src/package_json_serde.rs, src/tsconfig_serde.rs Entire files removed: trait-based cache, package.json, and tsconfig abstractions deleted.
src/lib.rs Resolver refactored: cache abstraction replaced with concrete Cache<Fs>; type signatures and constructors updated; all trait bounds and feature gates for fs_cache removed.
src/options.rs cwd field added; yarn_pnp field moved, documented, and defaults to env variable; test updated.
src/package_json.rs Trait-based package.json replaced by concrete struct with inherent methods and iterators; new enums for type and import/export kind; browser field resolution refactored.
src/resolution.rs Generic cache parameter removed; now uses concrete PackageJson type.
src/tests/alias.rs, src/tests/dependencies.rs, src/tests/fallback.rs, src/tests/full_specified.rs, src/tests/simple.rs, src/tests/resolution.rs Tests updated to use new resolver/file system construction, removing cache layer and related imports.
src/tests/exports_field.rs, src/tests/imports_field.rs Test helper types and functions updated to use new package_json types.
src/tests/memory_fs.rs FileSystem trait for MemoryFS implements new constructors for feature compatibility.
src/tests/pnp.rs PnP tests updated to set cwd and enable yarn_pnp explicitly in options.
src/tests/tsconfig_paths.rs Tests updated to use new TsConfig struct and resolver construction; serde-based tsconfig types removed.
src/tsconfig.rs Trait-based tsconfig replaced by concrete, serde-deserializable TsConfig and CompilerOptions structs; all trait methods become inherent methods; new parsing logic.
tests/integration_test.rs Imports and function signatures updated to use new, non-generic resolver and resolution types.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant NodeJS/CLI
    participant ResolverFactory
    participant Cache
    participant FileSystem
    participant YarnPnP (optional)

    User->>NodeJS/CLI: Run test or resolve request
    NodeJS/CLI->>ResolverFactory: Create Resolver (with options)
    ResolverFactory->>Cache: Initialize cache with FileSystem
    NodeJS/CLI->>ResolverFactory: Call resolve(specifier, options)
    ResolverFactory->>Cache: Lookup or compute CachedPath
    Cache->>FileSystem: Query filesystem for path, metadata, etc.
    alt Yarn PnP enabled
        Cache->>YarnPnP: Load PnP manifest and resolve if needed
    end
    Cache->>ResolverFactory: Return CachedPath/package.json/tsconfig
    ResolverFactory->>NodeJS/CLI: Return resolution result
    NodeJS/CLI->>User: Output result
Loading

Possibly related PRs

  • unrs/unrs-resolver#174: The main PR and the retrieved PR both involve extensive refactoring and feature additions related to Yarn Plug'n'Play support, TypeScript configuration resolution (including cycle detection for tsconfig extensions), and resolver option enhancements, indicating a strong direct relationship in the core resolver implementation and feature set.
  • unrs/unrs-resolver#146: Both PRs involve module resolution improvements, including handling of ModuleType enums and enhanced package.json lookup logic, showing direct code-level relation.
  • unrs/unrs-resolver#139: Refactors and simplifies resolver caching/filesystem abstractions and introduces Yarn PnP support; closely related to this PR’s PnP and cache changes.

Suggested labels

enhancement, dependencies

Poem

🐇
Refactored code, a leap ahead,
Traits are gone, and structs instead!
Caches unified, PnP in view,
Serde brings the configs through.
Tests now simpler, options neat,
This carrot’s change is quite a treat!
— A grateful rabbit 🥕

✨ Finishing Touches
  • 📝 Generate Docstrings

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
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@codecov
Copy link

codecov bot commented Jul 6, 2025

Codecov Report

Attention: Patch coverage is 95.82173% with 30 lines in your changes missing coverage. Please review.

Project coverage is 95.10%. Comparing base (57296ac) to head (e7744de).
Report is 11 commits behind head on main.

Files with missing lines Patch % Lines
src/cache.rs 95.17% 15 Missing ⚠️
src/tsconfig.rs 93.12% 9 Missing ⚠️
src/package_json.rs 96.49% 6 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #178      +/-   ##
==========================================
+ Coverage   92.54%   95.10%   +2.55%     
==========================================
  Files          14       12       -2     
  Lines        2953     2818     -135     
==========================================
- Hits         2733     2680      -53     
+ Misses        220      138      -82     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copy link

@ellipsis-dev ellipsis-dev bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Changes requested ❌

Reviewed everything up to 521b77a in 1 minute and 36 seconds. Click for details.
  • Reviewed 4782 lines of code in 39 files
  • Skipped 0 files when reviewing.
  • Skipped posting 6 draft comments. View those below.
  • Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. src/cache.rs:451
  • Draft comment:
    Typo in comment: "Need to trim the extra \0 introduces by ..." should likely be "... introduced by ...".
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% While the comment is technically correct and points out a real typo, it's an extremely minor documentation issue. The typo doesn't affect code functionality or readability in any meaningful way. According to the rules, we should not make purely informative comments or comments that are obvious/unimportant. The typo could theoretically cause confusion for future developers reading the code. Documentation quality is important for long-term maintainability. The meaning is still completely clear despite the minor grammatical error. This type of nitpick creates noise in code reviews without adding value. Delete the comment. While technically correct, it's too minor and doesn't meet the bar for useful code review comments.
2. src/lib.rs:84
  • Draft comment:
    Typographical issue: It looks like there is a missing colon in the re-export of options. This line currently reads options:{ but should use the double colon syntax options::{ to be consistent with the other re-exports.
  • Reason this comment was not posted:
    Comment was on unchanged code.
3. src/lib.rs:474
  • Draft comment:
    Typographical note: The comment "Make sure only relative or normal paths gets called" could be revised to "Make sure only relative or normal paths are called" for proper grammar.
  • Reason this comment was not posted:
    Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative and suggests a grammatical change to a comment in the code. It does not provide a code suggestion or address a potential issue in the code itself. Therefore, it should be removed according to the rules.
4. src/lib.rs:1231
  • Draft comment:
    Typo: The parameter name "alias_key_has_wild_card" might be intended to be "alias_key_has_wildcard". Consider renaming it for consistency.
  • Reason this comment was not posted:
    Comment was on unchanged code.
5. src/options.rs:193
  • Draft comment:
    Consider removing the question mark in the comment "Enable Yarn Plug'n'Play?." as it appears to be extraneous punctuation. It would be clearer as "Enable Yarn Plug'n'Play."
  • Reason this comment was not posted:
    Comment did not seem useful. Confidence is useful = 20% <= threshold 50% The comment is suggesting a minor punctuation change in a comment within the code. This is a stylistic suggestion and does not impact the functionality or correctness of the code. It does not ask for a test or suggest a code improvement, so it seems to be purely informative.
6. src/tests/pnp.rs:95
  • Draft comment:
    Typo in the test function name: "resolve_pnp_pkg_should_failed_while_disable_pnp_mode". Consider changing "should_failed" to "should_fail" for consistency.
  • Reason this comment was not posted:
    Comment was on unchanged code.

Workflow ID: wflow_OL11gnxLyRiv8UbN

You can customize Ellipsis by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.

@codspeed-hq
Copy link

codspeed-hq bot commented Jul 6, 2025

CodSpeed Performance Report

Merging #178 will not alter performance

Comparing chore/merge_upstream (e7744de) with main (57296ac)

Summary

✅ 3 untouched benchmarks

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

Merge in upstream refactor from oxc-project/oxc-resolver, replacing the previous fs_cache-based design with a new generic Cache and FileSystem abstraction, unifying PackageJson and TsConfig types, and updating all tests and N-API bindings to accommodate the new APIs.

  • Replace FsCache/FileSystemOs and serde-specific types with unified Cache<Fs> and file system traits
  • Migrate TsConfigSerde and PackageJsonSerde into single TsConfig and PackageJson structs driven by serde::Deserialize
  • Update tests and N-API layer to new constructors (new_with_file_system, Resolver::default(), etc.)

Reviewed Changes

Copilot reviewed 37 out of 39 changed files in this pull request and generated 3 comments.

Show a summary per file
File Description
tests/integration_test.rs Adjust imports and simplify resolve return type
src/tsconfig_serde.rs Delete serde-specific tsconfig implementation
src/tsconfig.rs Introduce TsConfig struct + impl, remove trait API
src/tests/*.rs Update tests to call new TsConfig::parse and API
src/tests/memory_fs.rs Adapt in-memory FS to new FileSystem trait
src/file_system.rs Update FileSystem trait and FileSystemOs impl
src/cache.rs New generic Cache<Fs> implementation
src/* (many) Remove generic C: Cache parameters, flatten types
napi/* Update N-API bindings to new resolver and options
Cargo.toml, justfile, CI, docs Bump dependency versions, add Yarn PnP support, CI tweaks

@JounQin JounQin force-pushed the chore/merge_upstream branch from 521b77a to 3311478 Compare July 6, 2025 12:03
Copy link

@ellipsis-dev ellipsis-dev bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Changes requested ❌

Reviewed 3311478 in 1 minute and 58 seconds. Click for details.
  • Reviewed 4789 lines of code in 40 files
  • Skipped 0 files when reviewing.
  • Skipped posting 13 draft comments. View those below.
  • Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. src/tsconfig.rs:247
  • Draft comment:
    Consider reviewing the error handling and robustness of template variable substitution in the build() method. Currently it uses strip_prefix in a single pass; if the template variable appears in a different position or multiple times this may not be handled.
  • Reason this comment was not posted:
    Comment was not on a location in the diff, so it can't be submitted as a review comment.
2. src/tsconfig.rs:287
  • Draft comment:
    The substitute_template_variable function currently only replaces the template variable if it appears as a prefix. Consider whether multiple occurrences or embedded template variables should be supported, or document that only a leading variable is supported.
  • Reason this comment was not posted:
    Comment was on unchanged code.
3. src/tsconfig.rs:316
  • Draft comment:
    In resolve_path_alias, the algorithm iterates over all keys with wildcards to find the longest prefix match. Consider pre-sorting or caching the keys for improved performance in projects with many path mappings.
  • Reason this comment was not posted:
    Comment was not on a location in the diff, so it can't be submitted as a review comment.
4. src/tsconfig.rs:624
  • Draft comment:
    The TsConfig::parse function ignores the result of json_strip_comments::strip. It might be clearer either to handle errors (if any) or document that any failure in comment stripping is non-fatal.
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% Looking at the code, json_strip_comments::strip() modifies the string in place and returns a Result. The function continues parsing the JSON regardless of whether stripping succeeded. This could potentially leave comments in the JSON if stripping failed, which might cause JSON parsing to fail. However, the code already handles JSON parsing errors via the Result return type. If comment stripping fails, the worst case is that serde_json will fail to parse and return an error. I may be underestimating the impact of comment stripping failures. There could be edge cases where partial comment stripping leaves the JSON in an invalid state. The JSON parser will catch any invalid JSON regardless of whether it was caused by failed comment stripping or other issues. The error handling is appropriate at the JSON parsing level. The comment raises a valid observation but the current error handling approach is reasonable - errors are caught at the JSON parsing stage. The comment should be removed as it doesn't identify a clear issue requiring code changes.
5. src/windows.rs:26
  • Draft comment:
    The use of unsafe blocks with from_encoded_bytes_unchecked appears acceptable given the context, but please ensure that the invariants of as_encoded_bytes are clearly documented to avoid future misuse.
  • Reason this comment was not posted:
    Confidence changes required: 30% <= threshold 50% None
6. tests/memory_fs.rs:31
  • Draft comment:
    In the add_file method, iterating over all ancestors and creating directories is acceptable for tests but might be inefficient for larger sets. Consider adding a note or using a recursive directory creation helper if this pattern is used in production.
  • Reason this comment was not posted:
    Confidence changes required: 50% <= threshold 50% None
7. src/cache.rs:54
  • Draft comment:
    Typo in comment: "we may joined a path like foo/bar and foo\bar on windows" should be "we may join a path like foo/bar and foo\bar on Windows".
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% While the comment is technically correct about the grammar and capitalization, it's a very minor documentation issue that doesn't affect functionality. The meaning is still clear in the original. Our rules say not to make purely informative comments and to avoid obvious/unimportant changes. The typo could make the codebase look less professional. Documentation quality is important for maintainability. While documentation quality matters, this is an extremely minor issue that doesn't impact understanding. The rules specifically say to avoid purely informative comments and unimportant changes. This comment should be deleted as it suggests a trivial documentation change that doesn't meaningfully improve the code.
8. src/cache.rs:452
  • Draft comment:
    Typo in comment: "Need to trim the extra \0 introduces by..." should be "Need to trim the extra \0 introduced by...".
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% According to the rules, we should not make purely informative comments. While this is a real typo, fixing it is not critical to the code's functionality. The comment is technically about changed code, but it's just about documentation, not logic. The rules don't explicitly address documentation fixes, but the spirit seems to be focused on substantive code issues. The typo could cause minor confusion for future readers. Documentation quality does matter for maintainability. While documentation quality matters, this is an extremely minor issue that doesn't impact code understanding. The meaning is still clear despite the typo. Delete the comment. The typo is too minor to warrant a PR comment, and we should focus on substantive code issues.
9. src/lib.rs:443
  • Draft comment:
    Typo in comment: The phrase "Make sure only path prefixes gets called" has a grammatical issue. Consider revising it to something like "Make sure only path prefixes are used" or "ensuring only path prefixes are called."
  • Reason this comment was not posted:
    Comment was on unchanged code.
10. src/lib.rs:474
  • Draft comment:
    Typo in comment: "Make sure only relative or normal paths gets called". Consider revising to "Make sure only relative or normal paths are called".
  • Reason this comment was not posted:
    Comment was on unchanged code.
11. src/options.rs:193
  • Draft comment:
    Typographical/nit: The comment "Enable Yarn Plug'n'Play?." contains both a question mark and a period. Consider removing one for clarity (e.g., "Enable Yarn Plug'n'Play" or "Enable Yarn Plug'n'Play?").
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the double punctuation being awkward, this is an extremely minor documentation issue. The meaning is still clear despite the punctuation. Comments about pure documentation style/formatting are generally not worth keeping unless they significantly impact readability or understanding. The comment does identify a real issue with the punctuation. Having both a question mark and period could be considered improper style. While technically correct, this level of nitpicking about documentation punctuation creates noise without adding significant value. The meaning is clear regardless of the punctuation. Delete this comment as it focuses on an extremely minor documentation formatting issue that doesn't meaningfully impact code quality or understanding.
12. src/package_json.rs:3
  • Draft comment:
    Typo suggestion: In the comment, 'Code related to export field are copied from ...', consider using 'exports field' instead of 'export field' if referring to the package.json "exports" field, and adjust the verb accordingly (e.g., "Code related to the exports field is copied from ...").
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While the comment is technically correct about both the grammar and terminology, doc comments are not critical to code functionality. The meaning is still clear despite the minor grammatical error. The comment feels overly pedantic and doesn't meaningfully improve code quality. The comment is accurate and the suggested fix would make the doc comment more professional. Doc comments are part of the public API documentation. While technically correct, this kind of minor grammatical fix creates noise in PR reviews and distracts from more important code quality issues. The current wording is understandable. Delete the comment as it's too minor and pedantic for a PR review. The grammatical issue doesn't impact code quality or understanding.
13. src/tests/imports_field.rs:110
  • Draft comment:
    There appears to be a typographical issue with the call to Box::leak. The syntax 'Box::leak::<'static>' looks incorrect—likely an extra '::' is present. Should this be 'Box::leak(Box::new(map))' or 'Box::leak::<_>(Box::new(map))'?
  • Reason this comment was not posted:
    Comment was on unchanged code.

Workflow ID: wflow_iayKzUP5n1SSnI61

You can customize Ellipsis by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🔭 Outside diff range comments (2)
src/lib.rs (2)

656-706: Consider refactoring to reduce cyclomatic complexity.

The static analysis correctly identifies high complexity (15, limit is 8). This method handles multiple concerns that could be extracted into helper methods:

  • Package.json main field resolution (lines 664-684)
  • Exports field handling (lines 693-701)
  • Index file loading (line 705)

Would you like me to propose a refactored version that extracts these concerns into separate methods to improve readability and maintainability?


1580-1679: Method exceeds complexity limits - consider breaking down.

Static analysis correctly identifies:

  • 222 lines of code (limit: 50)
  • Cyclomatic complexity: 18 (limit: 8)

While the complexity is partly due to the Node.js spec requirements, consider extracting:

  1. Main export resolution logic (lines 1617-1655) into resolve_main_export
  2. Subpath pattern matching (lines 1661-1672) into a separate method

This would improve testability and make the code easier to understand while maintaining spec compliance.

♻️ Duplicate comments (5)
src/file_system.rs (4)

194-194: Fix infinite recursion in read_to_string.

When yarn_pnp is false, this calls the trait method recursively instead of the OS implementation.

Apply this fix:

-        Self::read_to_string(path)
+        FileSystemOs::read_to_string(path)

209-209: Fix infinite recursion in VPath::Native branch.

This calls the trait method instead of the OS implementation.

Apply this fix:

-                        VPath::Native(path) => Self::metadata(&path),
+                        VPath::Native(path) => FileSystemOs::metadata(&path),

233-233: Fix infinite recursion in read_link.

This creates infinite recursion when yarn_pnp is disabled.

Apply this fix:

-        Self::read_link(path)
+        FileSystemOs::read_link(path)

214-214: Fix infinite recursion when yarn_pnp is disabled.

When the yarn_pnp feature or flag is disabled, this creates infinite recursion.

Apply this fix:

-        Self::metadata(path)
+        FileSystemOs::metadata(path)
src/package_json.rs (1)

268-268: Fix grammar in documentation.

The documentation is missing "are" after "that".

-    /// To reduce overall memory consumption, large fields that useless for pragmatic use are removed.
+    /// To reduce overall memory consumption, large fields that are useless for pragmatic use are removed.
🧹 Nitpick comments (8)
release-plz.toml (1)

1-3: Turning off semver_check removes an important safeguard

semver_check = false means breaking-change detection on publish is now disabled.
If this is just a temporary workaround (e.g. while the resolver is still pre-1.0), consider:

+[workspace]
+# TODO: revert to true once 0.x → 1.0 stabilises
 semver_check = false

or leaving it on and adding explicit overrides for false-positives ([semver]exceptions).
Please confirm the intent so we don’t accidentally ship a breaking API.

fixtures/pnp/index.test.mjs (1)

7-7: Fix unused parameter.

The parameter _ is defined but never used in the test function.

-test('resolver', (_) => {
+test('resolver', () => {
src/tests/memory_fs.rs (1)

44-54: _yarn_pnp argument is silently ignored

When the yarn_pnp feature is enabled, callers may expect the boolean to influence MemoryFS’s behaviour. Silently discarding it risks confusion and future misuse.

 #[cfg(feature = "yarn_pnp")]
-fn new(_yarn_pnp: bool) -> Self {
-    Self::default()
+fn new(yarn_pnp: bool) -> Self {
+    let mut fs = Self::default();
+    // If the value ever matters, store it or assert it’s `false` to make
+    // the current no-op explicit.
+    debug_assert!(
+        !yarn_pnp,
+        "MemoryFS does not yet support yarn_pnp=true – argument ignored"
+    );
+    fs
 }

At a minimum, add a comment or debug_assert! so the contract is explicit.

src/tests/exports_field.rs (1)

323-327: Leaking memory for test data – consider a safe helper instead.

Box::leak is fine for short-lived tests, but it permanently allocates on the process heap and can hide real leaks in CI sanitiser runs. A small static helper avoids the leak without extra dependencies:

-fn exports_field(value: serde_json::Value) -> ImportsExportsEntry<'static> {
-    // Don't do this at home:
-    let value = Box::leak::<'static>(Box::new(value));
-    ImportsExportsEntry(value)
-}
+fn exports_field(value: serde_json::Value) -> ImportsExportsEntry<'static> {
+    static mut SLOT: Option<serde_json::Value> = None;
+    // SAFETY: tests are single-threaded; we only write once per call.
+    unsafe {
+        SLOT = Some(value);
+        ImportsExportsEntry(SLOT.as_ref().unwrap())
+    }
+}

Not critical, but worth tidying if the test suite ever runs under leak detectors.

src/tests/pnp.rs (3)

13-18: Repeated resolver construction – extract a helper to de-duplicate.

Several tests create an identical Resolver::new(...) block differing only in fixture. A tiny helper keeps tests terse and reduces drift:

+fn pnp_resolver(fixture: &std::path::Path) -> Resolver {
+    Resolver::new(ResolveOptions {
+        cwd: Some(fixture.to_path_buf()),
+        yarn_pnp: true,
+        extensions: vec![".js".into()],
+        condition_names: vec!["import".into()],
+        ..ResolveOptions::default()
+    })
+}

-let resolver = Resolver::new(ResolveOptions { ... });
+let resolver = pnp_resolver(&fixture);

80-86: Same duplication nit.

This resolver instance can also use the proposed pnp_resolver helper.


128-133: Same default-dependency caveat applies here.
Consider adding explicit extensions / condition_names as above.

src/tsconfig.rs (1)

82-93: Consider avoiding intermediate Vec allocation.

The current implementation creates an intermediate Vec before converting to iterator. Consider returning an iterator directly:

-    pub fn extends(&self) -> impl Iterator<Item = &str> {
-        let specifiers = match &self.extends {
-            Some(ExtendsField::Single(specifier)) => {
-                vec![specifier.as_str()]
-            }
-            Some(ExtendsField::Multiple(specifiers)) => {
-                specifiers.iter().map(String::as_str).collect()
-            }
-            None => Vec::new(),
-        };
-        specifiers.into_iter()
-    }
+    pub fn extends(&self) -> impl Iterator<Item = &str> {
+        match &self.extends {
+            Some(ExtendsField::Single(specifier)) => {
+                std::iter::once(specifier.as_str())
+            }
+            Some(ExtendsField::Multiple(specifiers)) => {
+                // Use Either from itertools or create custom enum iterator
+                // For now, box the iterators for simplicity
+                Box::new(specifiers.iter().map(String::as_str)) as Box<dyn Iterator<Item = &str>>
+            }
+            None => {
+                Box::new(std::iter::empty()) as Box<dyn Iterator<Item = &str>>
+            }
+        }
+    }

Alternatively, keep the current implementation if the performance impact is negligible.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 57296ac and 3311478.

⛔ Files ignored due to path filters (1)
  • Cargo.lock is excluded by !**/*.lock
📒 Files selected for processing (39)
  • .github/workflows/ci.yml (1 hunks)
  • .prettierrc (1 hunks)
  • Cargo.toml (2 hunks)
  • README.md (1 hunks)
  • deny.toml (1 hunks)
  • fixtures/pnp/index.test.mjs (1 hunks)
  • fixtures/pnp/package.json (1 hunks)
  • justfile (2 hunks)
  • napi/Cargo.toml (1 hunks)
  • napi/index.d.ts (0 hunks)
  • napi/index.js (1 hunks)
  • napi/patch.mjs (2 hunks)
  • napi/src/lib.rs (4 hunks)
  • napi/src/options.rs (0 hunks)
  • release-plz.toml (1 hunks)
  • src/cache.rs (1 hunks)
  • src/error.rs (1 hunks)
  • src/file_system.rs (4 hunks)
  • src/fs_cache.rs (0 hunks)
  • src/lib.rs (48 hunks)
  • src/options.rs (6 hunks)
  • src/package_json.rs (3 hunks)
  • src/package_json_serde.rs (0 hunks)
  • src/resolution.rs (7 hunks)
  • src/tests/alias.rs (2 hunks)
  • src/tests/dependencies.rs (2 hunks)
  • src/tests/exports_field.rs (2 hunks)
  • src/tests/fallback.rs (2 hunks)
  • src/tests/full_specified.rs (3 hunks)
  • src/tests/imports_field.rs (2 hunks)
  • src/tests/memory_fs.rs (1 hunks)
  • src/tests/pnp.rs (7 hunks)
  • src/tests/resolution.rs (1 hunks)
  • src/tests/simple.rs (2 hunks)
  • src/tests/tsconfig_paths.rs (7 hunks)
  • src/tsconfig.rs (6 hunks)
  • src/tsconfig_serde.rs (0 hunks)
  • src/windows.rs (1 hunks)
  • tests/integration_test.rs (1 hunks)
💤 Files with no reviewable changes (5)
  • napi/index.d.ts
  • napi/src/options.rs
  • src/fs_cache.rs
  • src/package_json_serde.rs
  • src/tsconfig_serde.rs
🧰 Additional context used
🧠 Learnings (29)
📓 Common learnings
Learnt from: JounQin
PR: unrs/unrs-resolver#72
File: fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json:0-0
Timestamp: 2025-04-21T06:11:46.964Z
Learning: JounQin's fix for the dot alias issue in PR #72 addresses the problem by correctly normalizing paths in the `extend_tsconfig` method, ensuring that base URLs are properly resolved as absolute paths when extending tsconfigs, rather than adding special case handling for dot aliases in the resolver.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: fixtures/pnp/package.json:11-14
Timestamp: 2025-04-21T08:11:41.469Z
Learning: The project uses a justfile with an `install` task that includes running yarn in the fixtures/pnp directory to install dependencies with the command: `cd fixtures/pnp && yarn`.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T09:52:45.840Z
Learning: In Yarn PnP environments, some packages use nested package.json files for subpaths instead of the exports field. The resolver should check for these nested package.json files when resolving subpaths like `@atlaskit/pragmatic-drag-and-drop/combine` to correctly handle packages with this structure.
fixtures/pnp/package.json (8)
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: fixtures/pnp/package.json:11-14
Timestamp: 2025-04-21T08:11:41.469Z
Learning: The project uses a justfile with an `install` task that includes running yarn in the fixtures/pnp directory to install dependencies with the command: `cd fixtures/pnp && yarn`.
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#115
File: tests/resolve_test.rs:251-263
Timestamp: 2025-05-28T02:21:41.547Z
Learning: In pnpm workspaces, `pnpm install` must be run first to initialize dependencies and create the proper node_modules/.pnpm structure before tests can pass. Tests that rely on resolving packages will fail if dependencies haven't been installed yet.
Learnt from: JounQin
PR: unrs/unrs-resolver#144
File: napi/patch.mjs:5-5
Timestamp: 2025-06-10T13:53:02.983Z
Learning: Build-time scripts in napi/patch.mjs and similar build pipeline contexts don't require error handling for reading expected files like index.js, as these files are guaranteed to be present during the build process.
Learnt from: JounQin
PR: unrs/unrs-resolver#72
File: fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json:4-6
Timestamp: 2025-04-20T16:00:16.106Z
Learning: The configuration with `".": ["."]` in the paths setting in fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json is an intentional test case for testing the TypeScript dot alias resolution behavior, specifically related to issue #437 in the eslint-import-resolver-typescript repository.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T09:52:45.840Z
Learning: In Yarn PnP environments, some packages use nested package.json files for subpaths instead of the exports field. The resolver should check for these nested package.json files when resolving subpaths like `@atlaskit/pragmatic-drag-and-drop/combine` to correctly handle packages with this structure.
napi/Cargo.toml (5)
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: fixtures/pnp/package.json:11-14
Timestamp: 2025-04-21T08:11:41.469Z
Learning: The project uses a justfile with an `install` task that includes running yarn in the fixtures/pnp directory to install dependencies with the command: `cd fixtures/pnp && yarn`.
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T09:52:45.840Z
Learning: In Yarn PnP environments, some packages use nested package.json files for subpaths instead of the exports field. The resolver should check for these nested package.json files when resolving subpaths like `@atlaskit/pragmatic-drag-and-drop/combine` to correctly handle packages with this structure.
src/tests/resolution.rs (5)
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:13:59.358Z
Learning: In the unrs-resolver project, tests that intentionally document failing behavior (regression tests) should either use #[should_panic], assert on the expected error, or include clear documentation indicating they are intentional failing test cases.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:17:34.175Z
Learning: Test cases in unrs-resolver that intentionally document failing behavior should make the intent clear by either: 1) asserting on the expected error condition rather than the desired behavior, 2) using #[should_panic] for tests expected to panic, or 3) using #[ignore] with a reason to skip known failing tests in CI.
Learnt from: JounQin
PR: unrs/unrs-resolver#129
File: src/tests/pnp.rs:6-6
Timestamp: 2025-06-02T15:57:50.888Z
Learning: In the unrs-resolver project, std::env is acceptable for test cases even when deprecated, as the user prefers simpler approaches in test code compared to production code standards.
src/tests/fallback.rs (6)
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:13:59.358Z
Learning: In the unrs-resolver project, tests that intentionally document failing behavior (regression tests) should either use #[should_panic], assert on the expected error, or include clear documentation indicating they are intentional failing test cases.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:17:34.175Z
Learning: Test cases in unrs-resolver that intentionally document failing behavior should make the intent clear by either: 1) asserting on the expected error condition rather than the desired behavior, 2) using #[should_panic] for tests expected to panic, or 3) using #[ignore] with a reason to skip known failing tests in CI.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#129
File: src/tests/pnp.rs:6-6
Timestamp: 2025-06-02T15:57:50.888Z
Learning: In the unrs-resolver project, std::env is acceptable for test cases even when deprecated, as the user prefers simpler approaches in test code compared to production code standards.
Learnt from: JounQin
PR: unrs/unrs-resolver#72
File: fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json:4-6
Timestamp: 2025-04-20T16:00:16.106Z
Learning: The configuration with `".": ["."]` in the paths setting in fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json is an intentional test case for testing the TypeScript dot alias resolution behavior, specifically related to issue #437 in the eslint-import-resolver-typescript repository.
napi/patch.mjs (7)
Learnt from: JounQin
PR: unrs/unrs-resolver#144
File: napi/patch.mjs:5-5
Timestamp: 2025-06-10T13:53:02.983Z
Learning: Build-time scripts in napi/patch.mjs and similar build pipeline contexts don't require error handling for reading expected files like index.js, as these files are guaranteed to be present during the build process.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: fixtures/pnp/package.json:11-14
Timestamp: 2025-04-21T08:11:41.469Z
Learning: The project uses a justfile with an `install` task that includes running yarn in the fixtures/pnp directory to install dependencies with the command: `cd fixtures/pnp && yarn`.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T09:52:45.840Z
Learning: In Yarn PnP environments, some packages use nested package.json files for subpaths instead of the exports field. The resolver should check for these nested package.json files when resolving subpaths like `@atlaskit/pragmatic-drag-and-drop/combine` to correctly handle packages with this structure.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#72
File: fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json:0-0
Timestamp: 2025-04-21T06:11:46.964Z
Learning: JounQin's fix for the dot alias issue in PR #72 addresses the problem by correctly normalizing paths in the `extend_tsconfig` method, ensuring that base URLs are properly resolved as absolute paths when extending tsconfigs, rather than adding special case handling for dot aliases in the resolver.
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
README.md (6)
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: fixtures/pnp/package.json:11-14
Timestamp: 2025-04-21T08:11:41.469Z
Learning: The project uses a justfile with an `install` task that includes running yarn in the fixtures/pnp directory to install dependencies with the command: `cd fixtures/pnp && yarn`.
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T09:52:45.840Z
Learning: In Yarn PnP environments, some packages use nested package.json files for subpaths instead of the exports field. The resolver should check for these nested package.json files when resolving subpaths like `@atlaskit/pragmatic-drag-and-drop/combine` to correctly handle packages with this structure.
Learnt from: JounQin
PR: unrs/unrs-resolver#115
File: tests/resolve_test.rs:251-263
Timestamp: 2025-05-28T02:21:41.547Z
Learning: In pnpm workspaces, `pnpm install` must be run first to initialize dependencies and create the proper node_modules/.pnpm structure before tests can pass. Tests that rely on resolving packages will fail if dependencies haven't been installed yet.
.github/workflows/ci.yml (4)
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: fixtures/pnp/package.json:11-14
Timestamp: 2025-04-21T08:11:41.469Z
Learning: The project uses a justfile with an `install` task that includes running yarn in the fixtures/pnp directory to install dependencies with the command: `cd fixtures/pnp && yarn`.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
justfile (5)
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: fixtures/pnp/package.json:11-14
Timestamp: 2025-04-21T08:11:41.469Z
Learning: The project uses a justfile with an `install` task that includes running yarn in the fixtures/pnp directory to install dependencies with the command: `cd fixtures/pnp && yarn`.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
Learnt from: JounQin
PR: unrs/unrs-resolver#115
File: tests/resolve_test.rs:251-263
Timestamp: 2025-05-28T02:21:41.547Z
Learning: In pnpm workspaces, `pnpm install` must be run first to initialize dependencies and create the proper node_modules/.pnpm structure before tests can pass. Tests that rely on resolving packages will fail if dependencies haven't been installed yet.
src/tests/alias.rs (7)
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#72
File: fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json:4-6
Timestamp: 2025-04-20T16:00:16.106Z
Learning: The configuration with `".": ["."]` in the paths setting in fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json is an intentional test case for testing the TypeScript dot alias resolution behavior, specifically related to issue #437 in the eslint-import-resolver-typescript repository.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:13:59.358Z
Learning: In the unrs-resolver project, tests that intentionally document failing behavior (regression tests) should either use #[should_panic], assert on the expected error, or include clear documentation indicating they are intentional failing test cases.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:17:34.175Z
Learning: Test cases in unrs-resolver that intentionally document failing behavior should make the intent clear by either: 1) asserting on the expected error condition rather than the desired behavior, 2) using #[should_panic] for tests expected to panic, or 3) using #[ignore] with a reason to skip known failing tests in CI.
Learnt from: JounQin
PR: unrs/unrs-resolver#72
File: fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json:0-0
Timestamp: 2025-04-21T06:11:46.964Z
Learning: JounQin's fix for the dot alias issue in PR #72 addresses the problem by correctly normalizing paths in the `extend_tsconfig` method, ensuring that base URLs are properly resolved as absolute paths when extending tsconfigs, rather than adding special case handling for dot aliases in the resolver.
Learnt from: JounQin
PR: unrs/unrs-resolver#129
File: src/tests/pnp.rs:6-6
Timestamp: 2025-06-02T15:57:50.888Z
Learning: In the unrs-resolver project, std::env is acceptable for test cases even when deprecated, as the user prefers simpler approaches in test code compared to production code standards.
src/tests/simple.rs (5)
Learnt from: JounQin
PR: unrs/unrs-resolver#129
File: src/tests/pnp.rs:6-6
Timestamp: 2025-06-02T15:57:50.888Z
Learning: In the unrs-resolver project, std::env is acceptable for test cases even when deprecated, as the user prefers simpler approaches in test code compared to production code standards.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:13:59.358Z
Learning: In the unrs-resolver project, tests that intentionally document failing behavior (regression tests) should either use #[should_panic], assert on the expected error, or include clear documentation indicating they are intentional failing test cases.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:17:34.175Z
Learning: Test cases in unrs-resolver that intentionally document failing behavior should make the intent clear by either: 1) asserting on the expected error condition rather than the desired behavior, 2) using #[should_panic] for tests expected to panic, or 3) using #[ignore] with a reason to skip known failing tests in CI.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
fixtures/pnp/index.test.mjs (11)
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#115
File: tests/resolve_test.rs:251-263
Timestamp: 2025-05-28T02:21:41.547Z
Learning: In pnpm workspaces, `pnpm install` must be run first to initialize dependencies and create the proper node_modules/.pnpm structure before tests can pass. Tests that rely on resolving packages will fail if dependencies haven't been installed yet.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T09:52:45.840Z
Learning: In Yarn PnP environments, some packages use nested package.json files for subpaths instead of the exports field. The resolver should check for these nested package.json files when resolving subpaths like `@atlaskit/pragmatic-drag-and-drop/combine` to correctly handle packages with this structure.
Learnt from: JounQin
PR: unrs/unrs-resolver#72
File: fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json:4-6
Timestamp: 2025-04-20T16:00:16.106Z
Learning: The configuration with `".": ["."]` in the paths setting in fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json is an intentional test case for testing the TypeScript dot alias resolution behavior, specifically related to issue #437 in the eslint-import-resolver-typescript repository.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: fixtures/pnp/package.json:11-14
Timestamp: 2025-04-21T08:11:41.469Z
Learning: The project uses a justfile with an `install` task that includes running yarn in the fixtures/pnp directory to install dependencies with the command: `cd fixtures/pnp && yarn`.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:13:59.358Z
Learning: In the unrs-resolver project, tests that intentionally document failing behavior (regression tests) should either use #[should_panic], assert on the expected error, or include clear documentation indicating they are intentional failing test cases.
Learnt from: JounQin
PR: unrs/unrs-resolver#144
File: napi/patch.mjs:5-5
Timestamp: 2025-06-10T13:53:02.983Z
Learning: Build-time scripts in napi/patch.mjs and similar build pipeline contexts don't require error handling for reading expected files like index.js, as these files are guaranteed to be present during the build process.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:17:34.175Z
Learning: Test cases in unrs-resolver that intentionally document failing behavior should make the intent clear by either: 1) asserting on the expected error condition rather than the desired behavior, 2) using #[should_panic] for tests expected to panic, or 3) using #[ignore] with a reason to skip known failing tests in CI.
Learnt from: JounQin
PR: unrs/unrs-resolver#129
File: src/tests/pnp.rs:6-6
Timestamp: 2025-06-02T15:57:50.888Z
Learning: In the unrs-resolver project, std::env is acceptable for test cases even when deprecated, as the user prefers simpler approaches in test code compared to production code standards.
src/tests/dependencies.rs (5)
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:13:59.358Z
Learning: In the unrs-resolver project, tests that intentionally document failing behavior (regression tests) should either use #[should_panic], assert on the expected error, or include clear documentation indicating they are intentional failing test cases.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:17:34.175Z
Learning: Test cases in unrs-resolver that intentionally document failing behavior should make the intent clear by either: 1) asserting on the expected error condition rather than the desired behavior, 2) using #[should_panic] for tests expected to panic, or 3) using #[ignore] with a reason to skip known failing tests in CI.
Learnt from: JounQin
PR: unrs/unrs-resolver#129
File: src/tests/pnp.rs:6-6
Timestamp: 2025-06-02T15:57:50.888Z
Learning: In the unrs-resolver project, std::env is acceptable for test cases even when deprecated, as the user prefers simpler approaches in test code compared to production code standards.
tests/integration_test.rs (5)
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:17:34.175Z
Learning: Test cases in unrs-resolver that intentionally document failing behavior should make the intent clear by either: 1) asserting on the expected error condition rather than the desired behavior, 2) using #[should_panic] for tests expected to panic, or 3) using #[ignore] with a reason to skip known failing tests in CI.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:13:59.358Z
Learning: In the unrs-resolver project, tests that intentionally document failing behavior (regression tests) should either use #[should_panic], assert on the expected error, or include clear documentation indicating they are intentional failing test cases.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#129
File: src/tests/pnp.rs:6-6
Timestamp: 2025-06-02T15:57:50.888Z
Learning: In the unrs-resolver project, std::env is acceptable for test cases even when deprecated, as the user prefers simpler approaches in test code compared to production code standards.
napi/src/lib.rs (5)
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T09:52:45.840Z
Learning: In Yarn PnP environments, some packages use nested package.json files for subpaths instead of the exports field. The resolver should check for these nested package.json files when resolving subpaths like `@atlaskit/pragmatic-drag-and-drop/combine` to correctly handle packages with this structure.
Learnt from: JounQin
PR: unrs/unrs-resolver#129
File: src/tests/pnp.rs:6-6
Timestamp: 2025-06-02T15:57:50.888Z
Learning: In the unrs-resolver project, std::env is acceptable for test cases even when deprecated, as the user prefers simpler approaches in test code compared to production code standards.
src/tests/memory_fs.rs (3)
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:13:59.358Z
Learning: In the unrs-resolver project, tests that intentionally document failing behavior (regression tests) should either use #[should_panic], assert on the expected error, or include clear documentation indicating they are intentional failing test cases.
src/tests/pnp.rs (11)
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T09:52:45.840Z
Learning: In Yarn PnP environments, some packages use nested package.json files for subpaths instead of the exports field. The resolver should check for these nested package.json files when resolving subpaths like `@atlaskit/pragmatic-drag-and-drop/combine` to correctly handle packages with this structure.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: fixtures/pnp/package.json:11-14
Timestamp: 2025-04-21T08:11:41.469Z
Learning: The project uses a justfile with an `install` task that includes running yarn in the fixtures/pnp directory to install dependencies with the command: `cd fixtures/pnp && yarn`.
Learnt from: JounQin
PR: unrs/unrs-resolver#115
File: tests/resolve_test.rs:251-263
Timestamp: 2025-05-28T02:21:41.547Z
Learning: In pnpm workspaces, `pnpm install` must be run first to initialize dependencies and create the proper node_modules/.pnpm structure before tests can pass. Tests that rely on resolving packages will fail if dependencies haven't been installed yet.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:13:59.358Z
Learning: In the unrs-resolver project, tests that intentionally document failing behavior (regression tests) should either use #[should_panic], assert on the expected error, or include clear documentation indicating they are intentional failing test cases.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:17:34.175Z
Learning: Test cases in unrs-resolver that intentionally document failing behavior should make the intent clear by either: 1) asserting on the expected error condition rather than the desired behavior, 2) using #[should_panic] for tests expected to panic, or 3) using #[ignore] with a reason to skip known failing tests in CI.
Learnt from: JounQin
PR: unrs/unrs-resolver#72
File: fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json:4-6
Timestamp: 2025-04-20T16:00:16.106Z
Learning: The configuration with `".": ["."]` in the paths setting in fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json is an intentional test case for testing the TypeScript dot alias resolution behavior, specifically related to issue #437 in the eslint-import-resolver-typescript repository.
Learnt from: JounQin
PR: unrs/unrs-resolver#72
File: fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json:0-0
Timestamp: 2025-04-21T06:11:46.964Z
Learning: JounQin's fix for the dot alias issue in PR #72 addresses the problem by correctly normalizing paths in the `extend_tsconfig` method, ensuring that base URLs are properly resolved as absolute paths when extending tsconfigs, rather than adding special case handling for dot aliases in the resolver.
Learnt from: JounQin
PR: unrs/unrs-resolver#129
File: src/tests/pnp.rs:6-6
Timestamp: 2025-06-02T15:57:50.888Z
Learning: In the unrs-resolver project, std::env is acceptable for test cases even when deprecated, as the user prefers simpler approaches in test code compared to production code standards.
src/tests/full_specified.rs (5)
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:13:59.358Z
Learning: In the unrs-resolver project, tests that intentionally document failing behavior (regression tests) should either use #[should_panic], assert on the expected error, or include clear documentation indicating they are intentional failing test cases.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:17:34.175Z
Learning: Test cases in unrs-resolver that intentionally document failing behavior should make the intent clear by either: 1) asserting on the expected error condition rather than the desired behavior, 2) using #[should_panic] for tests expected to panic, or 3) using #[ignore] with a reason to skip known failing tests in CI.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#129
File: src/tests/pnp.rs:6-6
Timestamp: 2025-06-02T15:57:50.888Z
Learning: In the unrs-resolver project, std::env is acceptable for test cases even when deprecated, as the user prefers simpler approaches in test code compared to production code standards.
src/tests/exports_field.rs (6)
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:17:34.175Z
Learning: Test cases in unrs-resolver that intentionally document failing behavior should make the intent clear by either: 1) asserting on the expected error condition rather than the desired behavior, 2) using #[should_panic] for tests expected to panic, or 3) using #[ignore] with a reason to skip known failing tests in CI.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T09:52:45.840Z
Learning: In Yarn PnP environments, some packages use nested package.json files for subpaths instead of the exports field. The resolver should check for these nested package.json files when resolving subpaths like `@atlaskit/pragmatic-drag-and-drop/combine` to correctly handle packages with this structure.
Learnt from: JounQin
PR: unrs/unrs-resolver#129
File: src/tests/pnp.rs:6-6
Timestamp: 2025-06-02T15:57:50.888Z
Learning: In the unrs-resolver project, std::env is acceptable for test cases even when deprecated, as the user prefers simpler approaches in test code compared to production code standards.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:13:59.358Z
Learning: In the unrs-resolver project, tests that intentionally document failing behavior (regression tests) should either use #[should_panic], assert on the expected error, or include clear documentation indicating they are intentional failing test cases.
Cargo.toml (8)
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T09:52:45.840Z
Learning: In Yarn PnP environments, some packages use nested package.json files for subpaths instead of the exports field. The resolver should check for these nested package.json files when resolving subpaths like `@atlaskit/pragmatic-drag-and-drop/combine` to correctly handle packages with this structure.
Learnt from: JounQin
PR: unrs/unrs-resolver#129
File: src/tests/pnp.rs:6-6
Timestamp: 2025-06-02T15:57:50.888Z
Learning: In the unrs-resolver project, std::env is acceptable for test cases even when deprecated, as the user prefers simpler approaches in test code compared to production code standards.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:17:34.175Z
Learning: Test cases in unrs-resolver that intentionally document failing behavior should make the intent clear by either: 1) asserting on the expected error condition rather than the desired behavior, 2) using #[should_panic] for tests expected to panic, or 3) using #[ignore] with a reason to skip known failing tests in CI.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:13:59.358Z
Learning: In the unrs-resolver project, tests that intentionally document failing behavior (regression tests) should either use #[should_panic], assert on the expected error, or include clear documentation indicating they are intentional failing test cases.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: fixtures/pnp/package.json:11-14
Timestamp: 2025-04-21T08:11:41.469Z
Learning: The project uses a justfile with an `install` task that includes running yarn in the fixtures/pnp directory to install dependencies with the command: `cd fixtures/pnp && yarn`.
src/error.rs (6)
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T09:52:45.840Z
Learning: In Yarn PnP environments, some packages use nested package.json files for subpaths instead of the exports field. The resolver should check for these nested package.json files when resolving subpaths like `@atlaskit/pragmatic-drag-and-drop/combine` to correctly handle packages with this structure.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:17:34.175Z
Learning: Test cases in unrs-resolver that intentionally document failing behavior should make the intent clear by either: 1) asserting on the expected error condition rather than the desired behavior, 2) using #[should_panic] for tests expected to panic, or 3) using #[ignore] with a reason to skip known failing tests in CI.
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:13:59.358Z
Learning: In the unrs-resolver project, tests that intentionally document failing behavior (regression tests) should either use #[should_panic], assert on the expected error, or include clear documentation indicating they are intentional failing test cases.
src/tests/tsconfig_paths.rs (7)
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#72
File: fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json:4-6
Timestamp: 2025-04-20T16:00:16.106Z
Learning: The configuration with `".": ["."]` in the paths setting in fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json is an intentional test case for testing the TypeScript dot alias resolution behavior, specifically related to issue #437 in the eslint-import-resolver-typescript repository.
Learnt from: JounQin
PR: unrs/unrs-resolver#72
File: fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json:0-0
Timestamp: 2025-04-21T06:11:46.964Z
Learning: JounQin's fix for the dot alias issue in PR #72 addresses the problem by correctly normalizing paths in the `extend_tsconfig` method, ensuring that base URLs are properly resolved as absolute paths when extending tsconfigs, rather than adding special case handling for dot aliases in the resolver.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:17:34.175Z
Learning: Test cases in unrs-resolver that intentionally document failing behavior should make the intent clear by either: 1) asserting on the expected error condition rather than the desired behavior, 2) using #[should_panic] for tests expected to panic, or 3) using #[ignore] with a reason to skip known failing tests in CI.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:13:59.358Z
Learning: In the unrs-resolver project, tests that intentionally document failing behavior (regression tests) should either use #[should_panic], assert on the expected error, or include clear documentation indicating they are intentional failing test cases.
Learnt from: JounQin
PR: unrs/unrs-resolver#129
File: src/tests/pnp.rs:6-6
Timestamp: 2025-06-02T15:57:50.888Z
Learning: In the unrs-resolver project, std::env is acceptable for test cases even when deprecated, as the user prefers simpler approaches in test code compared to production code standards.
src/tests/imports_field.rs (5)
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:17:34.175Z
Learning: Test cases in unrs-resolver that intentionally document failing behavior should make the intent clear by either: 1) asserting on the expected error condition rather than the desired behavior, 2) using #[should_panic] for tests expected to panic, or 3) using #[ignore] with a reason to skip known failing tests in CI.
Learnt from: JounQin
PR: unrs/unrs-resolver#129
File: src/tests/pnp.rs:6-6
Timestamp: 2025-06-02T15:57:50.888Z
Learning: In the unrs-resolver project, std::env is acceptable for test cases even when deprecated, as the user prefers simpler approaches in test code compared to production code standards.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:13:59.358Z
Learning: In the unrs-resolver project, tests that intentionally document failing behavior (regression tests) should either use #[should_panic], assert on the expected error, or include clear documentation indicating they are intentional failing test cases.
src/options.rs (8)
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T09:52:45.840Z
Learning: In Yarn PnP environments, some packages use nested package.json files for subpaths instead of the exports field. The resolver should check for these nested package.json files when resolving subpaths like `@atlaskit/pragmatic-drag-and-drop/combine` to correctly handle packages with this structure.
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:17:34.175Z
Learning: Test cases in unrs-resolver that intentionally document failing behavior should make the intent clear by either: 1) asserting on the expected error condition rather than the desired behavior, 2) using #[should_panic] for tests expected to panic, or 3) using #[ignore] with a reason to skip known failing tests in CI.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T08:13:59.358Z
Learning: In the unrs-resolver project, tests that intentionally document failing behavior (regression tests) should either use #[should_panic], assert on the expected error, or include clear documentation indicating they are intentional failing test cases.
Learnt from: JounQin
PR: unrs/unrs-resolver#129
File: src/tests/pnp.rs:6-6
Timestamp: 2025-06-02T15:57:50.888Z
Learning: In the unrs-resolver project, std::env is acceptable for test cases even when deprecated, as the user prefers simpler approaches in test code compared to production code standards.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: fixtures/pnp/package.json:11-14
Timestamp: 2025-04-21T08:11:41.469Z
Learning: The project uses a justfile with an `install` task that includes running yarn in the fixtures/pnp directory to install dependencies with the command: `cd fixtures/pnp && yarn`.
napi/index.js (7)
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T09:52:45.840Z
Learning: In Yarn PnP environments, some packages use nested package.json files for subpaths instead of the exports field. The resolver should check for these nested package.json files when resolving subpaths like `@atlaskit/pragmatic-drag-and-drop/combine` to correctly handle packages with this structure.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: fixtures/pnp/package.json:11-14
Timestamp: 2025-04-21T08:11:41.469Z
Learning: The project uses a justfile with an `install` task that includes running yarn in the fixtures/pnp directory to install dependencies with the command: `cd fixtures/pnp && yarn`.
Learnt from: JounQin
PR: unrs/unrs-resolver#144
File: napi/patch.mjs:5-5
Timestamp: 2025-06-10T13:53:02.983Z
Learning: Build-time scripts in napi/patch.mjs and similar build pipeline contexts don't require error handling for reading expected files like index.js, as these files are guaranteed to be present during the build process.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#115
File: tests/resolve_test.rs:251-263
Timestamp: 2025-05-28T02:21:41.547Z
Learning: In pnpm workspaces, `pnpm install` must be run first to initialize dependencies and create the proper node_modules/.pnpm structure before tests can pass. Tests that rely on resolving packages will fail if dependencies haven't been installed yet.
src/file_system.rs (2)
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
src/tsconfig.rs (4)
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#72
File: fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json:0-0
Timestamp: 2025-04-21T06:11:46.964Z
Learning: JounQin's fix for the dot alias issue in PR #72 addresses the problem by correctly normalizing paths in the `extend_tsconfig` method, ensuring that base URLs are properly resolved as absolute paths when extending tsconfigs, rather than adding special case handling for dot aliases in the resolver.
Learnt from: JounQin
PR: unrs/unrs-resolver#72
File: fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json:4-6
Timestamp: 2025-04-20T16:00:16.106Z
Learning: The configuration with `".": ["."]` in the paths setting in fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json is an intentional test case for testing the TypeScript dot alias resolution behavior, specifically related to issue #437 in the eslint-import-resolver-typescript repository.
src/package_json.rs (4)
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T09:52:45.840Z
Learning: In Yarn PnP environments, some packages use nested package.json files for subpaths instead of the exports field. The resolver should check for these nested package.json files when resolving subpaths like `@atlaskit/pragmatic-drag-and-drop/combine` to correctly handle packages with this structure.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
src/lib.rs (5)
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#72
File: fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json:0-0
Timestamp: 2025-04-21T06:11:46.964Z
Learning: JounQin's fix for the dot alias issue in PR #72 addresses the problem by correctly normalizing paths in the `extend_tsconfig` method, ensuring that base URLs are properly resolved as absolute paths when extending tsconfigs, rather than adding special case handling for dot aliases in the resolver.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T09:52:45.840Z
Learning: In Yarn PnP environments, some packages use nested package.json files for subpaths instead of the exports field. The resolver should check for these nested package.json files when resolving subpaths like `@atlaskit/pragmatic-drag-and-drop/combine` to correctly handle packages with this structure.
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
🧬 Code Graph Analysis (6)
src/tests/fallback.rs (4)
src/tests/tsconfig_paths.rs (1)
  • resolver (390-414)
src/lib.rs (1)
  • new_with_file_system (150-152)
src/tests/dependencies.rs (1)
  • file_system (10-17)
src/tests/full_specified.rs (1)
  • file_system (10-25)
src/tests/dependencies.rs (2)
src/tests/tsconfig_paths.rs (1)
  • resolver (390-414)
src/lib.rs (1)
  • new_with_file_system (150-152)
tests/integration_test.rs (2)
tests/resolve_test.rs (1)
  • dir (5-7)
src/lib.rs (1)
  • resolve (182-189)
src/tests/memory_fs.rs (3)
src/file_system.rs (5)
  • new (15-15)
  • new (18-18)
  • new (77-79)
  • new (171-173)
  • new (176-178)
src/lib.rs (2)
  • new (136-146)
  • default (129-131)
src/options.rs (1)
  • default (496-526)
src/tests/full_specified.rs (3)
src/tests/tsconfig_paths.rs (1)
  • resolver (390-414)
src/lib.rs (1)
  • new_with_file_system (150-152)
src/tests/dependencies.rs (1)
  • file_system (10-17)
src/tsconfig.rs (4)
src/package_json.rs (2)
  • path (75-77)
  • directory (96-99)
src/specifier.rs (2)
  • path (13-15)
  • path (71-74)
src/lib.rs (5)
  • new (136-146)
  • extend_tsconfig (1439-1459)
  • tsconfig (1391-1394)
  • tsconfig (1445-1448)
  • resolve (182-189)
tests/integration_test.rs (2)
  • tsconfig (47-52)
  • resolve (13-16)
🪛 GitHub Check: Codacy Static Code Analysis
napi/patch.mjs

[warning] 27-27: napi/patch.mjs#L27
Found writeFileSync from package "node:fs" with non literal argument at index 0

fixtures/pnp/index.test.mjs

[failure] 7-7: fixtures/pnp/index.test.mjs#L7
'_' is defined but never used.


[failure] 7-7: fixtures/pnp/index.test.mjs#L7
'_' is defined but never used.

src/tsconfig.rs

[warning] 136-136: src/tsconfig.rs#L136
Method extend_tsconfig has 74 lines of code (limit is 50)


[warning] 136-136: src/tsconfig.rs#L136
Method extend_tsconfig has a cyclomatic complexity of 25 (limit is 8)


[warning] 241-241: src/tsconfig.rs#L241
Method build has a cyclomatic complexity of 9 (limit is 8)


[warning] 316-316: src/tsconfig.rs#L316
Method resolve_path_alias has a cyclomatic complexity of 9 (limit is 8)

src/package_json.rs

[warning] 23-23: src/package_json.rs#L23
Method fmt has 15 parameters (limit is 8)


[warning] 23-23: src/package_json.rs#L23
Method fmt has 249 lines of code (limit is 50)

src/cache.rs

[notice] 422-422: src/cache.rs#L422
Detected 'unsafe' usage, please audit for secure usage

src/lib.rs

[warning] 656-656: src/lib.rs#L656
Method load_as_directory has a cyclomatic complexity of 15 (limit is 8)


[warning] 1580-1580: src/lib.rs#L1580
Method package_exports_resolve has 222 lines of code (limit is 50)


[warning] 1580-1580: src/lib.rs#L1580
Method package_exports_resolve has a cyclomatic complexity of 18 (limit is 8)

🪛 GitHub Check: codecov/patch
src/tsconfig.rs

[warning] 534-536: src/tsconfig.rs#L534-L536
Added lines #L534 - L536 were not covered by tests


[warning] 544-546: src/tsconfig.rs#L544-L546
Added lines #L544 - L546 were not covered by tests


[warning] 554-556: src/tsconfig.rs#L554-L556
Added lines #L554 - L556 were not covered by tests

src/package_json.rs

[warning] 25-25: src/package_json.rs#L25
Added line #L25 was not covered by tests


[warning] 86-88: src/package_json.rs#L86-L88
Added lines #L86 - L88 were not covered by tests


[warning] 236-236: src/package_json.rs#L236
Added line #L236 was not covered by tests


[warning] 317-317: src/package_json.rs#L317
Added line #L317 was not covered by tests

src/cache.rs

[warning] 241-241: src/cache.rs#L241
Added line #L241 was not covered by tests


[warning] 266-270: src/cache.rs#L266-L270
Added lines #L266 - L270 were not covered by tests


[warning] 460-460: src/cache.rs#L460
Added line #L460 was not covered by tests


[warning] 510-512: src/cache.rs#L510-L512
Added lines #L510 - L512 were not covered by tests


[warning] 533-535: src/cache.rs#L533-L535
Added lines #L533 - L535 were not covered by tests


[warning] 544-545: src/cache.rs#L544-L545
Added lines #L544 - L545 were not covered by tests

⏰ Context from checks skipped due to timeout of 90000ms (2)
  • GitHub Check: Codacy Static Code Analysis
  • GitHub Check: Benchmark
🔇 Additional comments (64)
.prettierrc (1)

2-2: printWidth bump looks good

Adopting 120 chars matches current Rust & TS sources that already exceed 80.
No further action needed.

deny.toml (1)

97-97: Re-ordering of allow list is a no-op

Only the sequence changed; tooling treats the array as an unordered set.
Nothing to review here.

src/windows.rs (1)

44-44: Test rename improves clarity

Dropping the “try_” prefix makes the intent consistent with the production fn name. 👍

fixtures/pnp/package.json (1)

4-6: Helpful test script added

Using yarn node ensures PnP hooks are active during the fixture test run.
No issues spotted.

src/tests/resolution.rs (1)

3-3: LGTM! Clean import simplification.

The removal of unused imports and reliance on type inference align well with the broader refactoring that eliminates the FsCache abstraction.

Also applies to: 7-7

napi/Cargo.toml (1)

42-42: LGTM! Enabling Yarn PnP by default.

Adding yarn_pnp to the default features aligns with the PR objectives to integrate Yarn PnP support throughout the resolver ecosystem.

napi/index.js (1)

392-394: LGTM! Proper Yarn PnP detection.

The use of process.versions.pnp is the correct standard method for detecting Yarn PnP environments, and setting the environment variable enables the Rust resolver to respond appropriately.

.github/workflows/ci.yml (1)

46-46: LGTM! Simplified test orchestration.

Consolidating the test commands into just test improves maintainability and aligns with the enhanced justfile that now handles both Rust and PnP-related testing.

Also applies to: 49-49

src/tests/alias.rs (1)

13-16: LGTM! Consistent with architectural refactoring.

The changes properly align with the removal of the FsCache abstraction, using the new new_with_file_system constructor that handles caching internally. This simplifies the test setup while maintaining the same test coverage.

Also applies to: 37-39

src/tests/fallback.rs (2)

6-6: LGTM: Imports updated for simplified resolver construction.

The removal of Arc and FsCache imports aligns with the codebase refactor that consolidates caching into a unified Cache<Fs> implementation.

Also applies to: 9-9


31-32: LGTM: Resolver construction simplified correctly.

The change from new_with_cache(Arc::new(FsCache::new(file_system))) to new_with_file_system(file_system, ...) correctly uses the new API that internally handles the cache creation and Arc wrapping, as seen in src/lib.rs lines 150-152.

napi/patch.mjs (2)

3-3: LGTM: Variable rename for consistency.

The rename from fileUrl to filename improves clarity since the variable holds a filename rather than a URL object.

Also applies to: 5-5, 27-27


21-25: LGTM: Yarn PnP support integration.

The added code correctly detects Yarn PnP environment via process.versions.pnp and sets the UNRS_RESOLVER_YARN_PNP environment variable to enable PnP support. This aligns with the broader Yarn PnP integration described in the AI summary.

Note: The static analysis warning about writeFileSync with non-literal argument is a false positive - filename is safely constructed from import.meta.url in this build context.

src/tests/full_specified.rs (2)

5-5: LGTM: Imports cleaned up for simplified resolver construction.

Removal of Arc and FsCache imports is consistent with the codebase refactor that eliminates the FsCache abstraction in favor of a unified Cache<Fs> implementation.

Also applies to: 8-8


31-32: LGTM: Both test functions updated consistently.

The resolver construction is properly updated in both test() and resolve_to_context() functions to use the new new_with_file_system API, maintaining consistency across the test module.

Also applies to: 82-83

src/tests/dependencies.rs (2)

5-5: LGTM: Import cleanup consistent with codebase refactor.

Removal of Arc and FsCache imports aligns with the elimination of the FsCache abstraction across the test suite.

Also applies to: 8-8


23-24: LGTM: Resolver construction updated correctly.

The change to use new_with_file_system directly with the MemoryFS instance follows the new simplified API pattern consistently implemented across all test files.

README.md (1)

87-93: LGTM: Clear documentation for Yarn PnP support.

The added section accurately documents the requirements for Yarn Plug'n'Play to function, including the environment detection (process.versions.pnp), manifest file requirement (.pnp.cjs), and multi-project limitations. This aligns well with the PnP support infrastructure added throughout the codebase.

tests/integration_test.rs (2)

6-6: LGTM: Import cleanup aligns with cache abstraction removal.

The removal of unused imports (FileSystemOs, FsCache, PackageJson) is consistent with the broader refactoring that eliminates trait-based caching abstractions.


13-13: LGTM: Return type simplification reflects unified cache implementation.

The change from generic Resolution<FsCache<FileSystemOs>> to non-generic Resolution correctly implements the consolidated resolver design with unified Cache<Fs> type.

src/tests/simple.rs (2)

68-68: LGTM: Import cleanup removes unused cache abstractions.

The removal of Arc and FsCache imports is consistent with the refactoring that eliminates these caching abstractions in favor of direct file system usage.


77-78: LGTM: Simplified resolver construction eliminates cache wrappers.

The change from new_with_cache(Arc<FsCache<MemoryFS>>) to new_with_file_system(MemoryFS, ResolveOptions::default()) correctly implements the simplified resolver API without intermediate caching layers.

fixtures/pnp/index.test.mjs (1)

8-11: LGTM: Test correctly verifies PnP resolver compatibility.

The test implementation properly validates that the custom resolver produces the same results as the official pnpapi.resolveRequest for the 'is-even' module, ensuring compatibility with Yarn PnP resolution.

justfile (2)

30-30: LGTM: Added documentation generation to readiness checks.

Including just doc in the ready recipe ensures documentation is generated and validated as part of the pre-release checks.


58-58: LGTM: Expanded test coverage with standard cargo test and PnP tests.

The addition of cargo test (without --all-features) and cd fixtures/pnp && yarn test enhances test coverage by including both standard Rust tests and the new Yarn PnP integration tests.

Also applies to: 62-62

napi/src/lib.rs (4)

15-15: LGTM: Removed unused import.

The removal of PackageJson from imports is consistent with the refactoring that eliminates unused trait-based abstractions.


154-154: LGTM: Simplified resolver construction.

Inlining ResolveOptions::default() directly in the Resolver::new call eliminates an unnecessary intermediate variable and simplifies the code.


192-192: LGTM: Explicit cwd field assignment.

Setting cwd: None explicitly instead of relying on the default value makes the intent clearer in the options normalization.


282-283: LGTM: Yarn PnP configuration shift to compile-time detection.

The conditional compilation and use of default.yarn_pnp correctly implements the design change from dynamic option configuration to compile-time feature detection combined with runtime environment variable control.

src/tests/imports_field.rs (1)

100-100: Type alias update looks good

ImportsExportsMap correctly replaces the Serde-specific type in the TestCase struct.

src/tests/exports_field.rs (2)

9-11: Import update looks correct.

The new ImportsExportsEntry type replaces the removed ImportsExportsSerdeEntry and compiles cleanly with the generic lifetime.
No further action required.


318-318: Struct field rename acknowledged.

Field type updated to ImportsExportsEntry<'static>; matches the refactor and keeps the public surface intact.

src/tests/pnp.rs (4)

96-103: Test correctly asserts non-PnP failure – looks good.


110-114: Missing extensions & condition_names may couple test to defaults.

Unlike earlier tests, this resolver relies on default option values. If the defaults change (e.g. extensions stops including .js) the test will silently break.

 let resolver = Resolver::new(ResolveOptions {
     cwd: Some(fixture.clone()),
     yarn_pnp: true,
+    extensions: vec![".js".into()],
+    condition_names: vec!["import".into()],
     ..ResolveOptions::default()
 });

147-151: Explicit extensions recommended for stability.

Add extensions: vec![".js".into()] to guard against future default changes (see previous comment).


187-191: Global-cache test follows new option shape – LGTM.

src/error.rs (2)

117-123: LGTM! Well-structured error variants for Yarn PnP support.

The new error variants provide appropriate error handling for Yarn PnP manifest loading failures and PnP-specific errors. The conditional compilation ensures they're only included when the yarn_pnp feature is enabled.


133-140: Good removal of feature gating.

Removing the #[cfg(feature = "fs_cache")] attribute makes the from_serde_json_error method always available, which aligns with the broader refactoring that removes the fs_cache feature abstraction.

Cargo.toml (2)

82-94: LGTM! Dependency simplification improves maintainability.

The version generalization and removal of optional flags reduces complexity while maintaining functionality. This aligns well with the broader code simplification.


108-111: Good feature simplification and documentation update.

Removing the default features and updating the comment to reference PackageJson::raw_json instead of PackageJsonSerde::raw_json correctly reflects the transition from trait-based to concrete type implementations.

src/tests/tsconfig_paths.rs (3)

8-8: LGTM! Correct import update for concrete types.

The import change from trait-based to concrete TsConfig aligns with the broader refactoring removing trait abstractions.


151-151: Good migration from trait-based to concrete parsing.

The consistent update from TsConfigSerde::parse to TsConfig::parse across all test functions properly implements the transition to concrete type implementations.

Also applies to: 181-181, 212-212


343-347: Excellent simplification of resolver construction.

The removal of FsCache wrapper and Arc usage, along with the transition to new_with_file_system, significantly simplifies the test code while maintaining the same functionality.

Also applies to: 390-390, 413-413

src/resolution.rs (2)

7-7: Excellent simplification of the Resolution type.

Removing the generic cache parameter and using concrete PackageJson significantly simplifies the type system while maintaining all functionality. This makes the code more readable and easier to work with.

Also applies to: 19-19, 29-29


41-51: LGTM! Consistent removal of generic parameters.

All trait implementations and methods are correctly updated to remove generic parameters. The functionality remains the same while the code becomes much simpler and more maintainable.

Also applies to: 53-63, 65-70, 72-99

src/options.rs (3)

14-16: Good addition of testing-specific field.

The cwd field with clear documentation that it's for testing purposes is a clean way to support test scenarios without affecting production usage.


193-199: Excellent environment variable-based configuration.

Using the UNRS_RESOLVER_YARN_PNP environment variable to control Yarn PnP enables runtime configuration without requiring code changes. The documentation clearly explains the intended usage.

Also applies to: 523-524


498-498: LGTM! Consistent field initialization.

The default implementation and test updates properly initialize the new fields with appropriate values.

Also applies to: 660-660, 677-677

src/file_system.rs (3)

14-19: Well-designed conditional constructor pattern.

The conditional compilation approach for the new method allows runtime configuration of Yarn PnP support while maintaining backward compatibility.


113-117: Appropriate struct design for runtime PnP configuration.

The combination of compile-time feature flag and runtime boolean provides flexibility for enabling Yarn PnP support dynamically.


170-179: Correct implementation of conditional constructor.

The implementation properly initializes the struct fields based on the feature flag.

src/tsconfig.rs (3)

18-39: Well-designed TsConfig struct with proper serde integration.

The struct properly separates runtime fields (root, path) from serialized configuration, and the use of ExtendsField enum elegantly handles both single and multiple extends scenarios.


136-234: Method complexity is acceptable given the requirements.

While static analysis flags high complexity, the method's logic is straightforward - it systematically inherits each compiler option if not already set. The current implementation is readable and maintainable.


619-633: Robust JSON parsing with proper preprocessing.

The implementation correctly handles BOM and comments before parsing, and properly initializes runtime fields.

src/cache.rs (3)

26-44: Excellent concurrent cache design with performance optimizations.

The use of thread-local storage for scratch paths and thread IDs is clever, and the identity hasher for pre-hashed paths avoids redundant hashing. The papaya concurrent collections are appropriate for this use case.


236-284: Robust symlink resolution with circular reference detection.

The implementation cleverly uses thread IDs to detect circular symlinks while allowing concurrent canonicalization by different threads. The atomic operations ensure thread safety.


111-153: Well-implemented package.json caching with dependency tracking.

The implementation properly handles lazy loading, path canonicalization when symlinks are enabled, and updates the resolve context with file/missing dependencies.

src/package_json.rs (2)

39-65: Well-designed PackageJson struct with memory optimization.

The use of Arc for raw_json enables efficient sharing, and the public fields provide direct access to commonly used properties.


182-204: Correct implementation of browser field resolution.

The method properly handles both string-based and path-based aliasing, and correctly returns an error for false values per the browser field specification.

src/lib.rs (5)

101-101: Good architectural simplification!

The removal of the generic cache parameter and use of concrete CachedPath type significantly simplifies the API and makes the resolver easier to use.

Also applies to: 117-120


136-147: Clean constructor implementation with proper feature handling.

The use of cfg_if for conditional compilation based on the yarn_pnp feature is well-structured, and the cache initialization is straightforward.


938-1020: Excellent refactoring of the Yarn PnP implementation!

The unified cache integration and comprehensive handling of PnP resolution scenarios is well-implemented. The special handling for "pnpapi" builtin and symbol-linked packages shows good attention to detail.


1832-1856: Well-designed helper function with efficient string handling.

Good use of Cow<'a, str> to avoid unnecessary string allocations and clear separation of pattern matching logic.


134-152: Verify API compatibility after removing generic cache parameter

Automated checks indicate no residual references to the old cache APIs and no explicit generic instantiations of ResolverGeneric remain. However, please manually confirm the following:

  • NAPI bindings (e.g. in your Node addon code) have been updated to call the new ResolverGeneric::new and new_with_file_system signatures correctly.
  • Any tests or example code that require a custom FileSystem now invoke new_with_file_system rather than the removed generic constructor.

@socket-security
Copy link

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff Package Supply Chain
Security
Vulnerability Quality Maintenance License
Updated@​napi-rs/​cli@​3.0.0-alpha.91 ⏵ 3.0.0-alpha.9297 -21008497100

View full report

@sonarqubecloud
Copy link

sonarqubecloud bot commented Jul 6, 2025

Copy link

@ellipsis-dev ellipsis-dev bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Changes requested ❌

Reviewed e7744de in 1 minute and 39 seconds. Click for details.
  • Reviewed 128 lines of code in 6 files
  • Skipped 1 files when reviewing.
  • Skipped posting 5 draft comments. View those below.
  • Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. Cargo.toml:86
  • Draft comment:
    Verify that changing the 'papaya' dependency version from '0.2.1' to '0.2' is intentional and does not widen the version range unexpectedly.
  • Reason this comment was not posted:
    Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is asking the PR author to verify their intention regarding a dependency version change. According to the rules, comments should not ask the author to confirm their intention or verify behavior. Therefore, this comment violates the rules.
2. fixtures/pnp/index.test.mjs:7
  • Draft comment:
    Minor style improvement: The unused parameter was removed in the test arrow function. This looks fine.
  • Reason this comment was not posted:
    Confidence changes required: 33% <= threshold 50% None
3. napi/Cargo.toml:25
  • Draft comment:
    Dependency versions for 'napi' and 'napi-derive' have been bumped to beta.12. Ensure these updates are compatible with the existing API.
  • Reason this comment was not posted:
    Confidence changes required: 50% <= threshold 50% None
4. napi/resolver.wasi.cjs:73
  • Draft comment:
    Typographical error: In the comment, use "consists" instead of "is consist" (i.e., "a worker consists of two handles...").
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the grammatical error exists and the correction is accurate, comments about typos and grammar in comments are generally not important enough to warrant a PR comment. The meaning is still clear despite the minor grammatical error. This kind of feedback could be better provided in a more informal way or during code review discussions. The grammar error could potentially confuse non-native English speakers. Documentation quality is important for maintainability. While documentation quality matters, this is a minor grammatical error that doesn't impact code functionality or significantly impair understanding. The meaning remains clear despite the error. Delete the comment as it's too minor and doesn't affect code functionality or comprehension.
5. napi/resolver.wasi.cjs:85
  • Draft comment:
    Typographical error: The condition appears to be incorrect. It's checking 'if (kPublicPort)' again instead of checking 'if (kHandle)'.
  • Reason this comment was not posted:
    Marked as duplicate.

Workflow ID: wflow_s9Drc9z7UOhxBDAq

You can customize Ellipsis by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3311478 and e7744de.

⛔ Files ignored due to path filters (2)
  • Cargo.lock is excluded by !**/*.lock
  • pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml
📒 Files selected for processing (5)
  • Cargo.toml (2 hunks)
  • fixtures/pnp/index.test.mjs (1 hunks)
  • napi/Cargo.toml (2 hunks)
  • napi/resolver.wasi.cjs (1 hunks)
  • package.json (1 hunks)
✅ Files skipped from review due to trivial changes (2)
  • package.json
  • fixtures/pnp/index.test.mjs
🚧 Files skipped from review as they are similar to previous changes (2)
  • napi/Cargo.toml
  • Cargo.toml
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#136
File: src/tests/extension_alias.rs:36-46
Timestamp: 2025-06-05T18:52:30.363Z
Learning: The fixtures/yarn directory in the unrs-resolver project requires running `yarn install` to install TypeScript dependencies before tests can run, similar to other fixture directories like fixtures/pnp. The test in src/tests/extension_alias.rs depends on the installed TypeScript package providing lib/typescript.d.ts and related files.
Learnt from: JounQin
PR: unrs/unrs-resolver#72
File: fixtures/tsconfig/cases/dot-alias/tsconfigs/tsconfig.base.json:0-0
Timestamp: 2025-04-21T06:11:46.964Z
Learning: JounQin's fix for the dot alias issue in PR #72 addresses the problem by correctly normalizing paths in the `extend_tsconfig` method, ensuring that base URLs are properly resolved as absolute paths when extending tsconfigs, rather than adding special case handling for dot aliases in the resolver.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: src/tests/pnp.rs:116-133
Timestamp: 2025-04-21T09:52:45.840Z
Learning: In Yarn PnP environments, some packages use nested package.json files for subpaths instead of the exports field. The resolver should check for these nested package.json files when resolving subpaths like `@atlaskit/pragmatic-drag-and-drop/combine` to correctly handle packages with this structure.
Learnt from: JounQin
PR: unrs/unrs-resolver#40
File: src/tests/resolve.rs:121-136
Timestamp: 2025-03-29T04:14:03.715Z
Learning: For tests involving npm/yarn package resolution in the unrs-resolver project, dependencies must be installed first using the appropriate package manager commands (pnpm i, yarn) in both the root directory and fixture directories like fixtures/pnp and fixtures/misc/nested-package-json.
Learnt from: JounQin
PR: unrs/unrs-resolver#75
File: fixtures/pnp/package.json:11-14
Timestamp: 2025-04-21T08:11:41.469Z
Learning: The project uses a justfile with an `install` task that includes running yarn in the fixtures/pnp directory to install dependencies with the command: `cd fixtures/pnp && yarn`.
napi/resolver.wasi.cjs (1)
Learnt from: JounQin
PR: unrs/unrs-resolver#144
File: napi/patch.mjs:5-5
Timestamp: 2025-06-10T13:53:02.983Z
Learning: Build-time scripts in napi/patch.mjs and similar build pipeline contexts don't require error handling for reading expected files like index.js, as these files are guaranteed to be present during the build process.
⏰ Context from checks skipped due to timeout of 90000ms (6)
  • GitHub Check: Codacy Static Code Analysis
  • GitHub Check: Benchmark
  • GitHub Check: Test (ubuntu-latest)
  • GitHub Check: Test (macos-14)
  • GitHub Check: Test (windows-latest)
  • GitHub Check: Analyze (javascript-typescript)

@JounQin JounQin merged commit e7744de into main Jul 6, 2025
25 checks passed
@JounQin JounQin deleted the chore/merge_upstream branch July 6, 2025 12:16
@JounQin JounQin mentioned this pull request Jul 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

upstream Blocked by upstream

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants