feat: merge from upstream oxc-project/oxc-resolver - 8th#178
Conversation
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`.
WalkthroughThis update removes trait-based abstractions for caching, package.json, and tsconfig handling, replacing them with concrete, Serde-deserializable structs and a unified, generic Changes
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
Possibly related PRs
Suggested labels
Poem
✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed 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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov ReportAttention: Patch coverage is
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. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Caution
Changes requested ❌
Reviewed everything up to 521b77a in 1 minute and 36 seconds. Click for details.
- Reviewed
4782lines of code in39files - Skipped
0files when reviewing. - Skipped posting
6draft 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 ofoptions. This line currently readsoptions:{but should use the double colon syntaxoptions::{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%<= threshold50%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%<= threshold50%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 by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
CodSpeed Performance ReportMerging #178 will not alter performanceComparing Summary
|
There was a problem hiding this comment.
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/FileSystemOsand serde-specific types with unifiedCache<Fs>and file system traits - Migrate
TsConfigSerdeandPackageJsonSerdeinto singleTsConfigandPackageJsonstructs driven byserde::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 |
521b77a to
3311478
Compare
There was a problem hiding this comment.
Caution
Changes requested ❌
Reviewed 3311478 in 1 minute and 58 seconds. Click for details.
- Reviewed
4789lines of code in40files - Skipped
0files when reviewing. - Skipped posting
13draft 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%<= threshold50%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%<= threshold50%None
7. src/cache.rs:54
- Draft comment:
Typo in comment: "we may joined a path likefoo/barandfoo\baron windows" should be "we may join a path likefoo/barandfoo\baron 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 by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
There was a problem hiding this comment.
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:
- Main export resolution logic (lines 1617-1655) into
resolve_main_export- 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_pnpis 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 offsemver_checkremoves an important safeguard
semver_check = falsemeans 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 = falseor 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_pnpargument is silently ignoredWhen the
yarn_pnpfeature is enabled, callers may expect the boolean to influenceMemoryFS’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::leakis 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 infixture. 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_resolverhelper.
128-133: Same default-dependency caveat applies here.
Consider adding explicitextensions/condition_namesas 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
⛔ Files ignored due to path filters (1)
Cargo.lockis 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:printWidthbump looks goodAdopting 120 chars matches current Rust & TS sources that already exceed 80.
No further action needed.deny.toml (1)
97-97: Re-ordering ofallowlist is a no-opOnly the sequence changed; tooling treats the array as an unordered set.
Nothing to review here.src/windows.rs (1)
44-44: Test rename improves clarityDropping the “try_” prefix makes the intent consistent with the production fn name. 👍
fixtures/pnp/package.json (1)
4-6: Helpfultestscript addedUsing
yarn nodeensures 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
FsCacheabstraction.Also applies to: 7-7
napi/Cargo.toml (1)
42-42: LGTM! Enabling Yarn PnP by default.Adding
yarn_pnpto 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.pnpis 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 testimproves 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
FsCacheabstraction, using the newnew_with_file_systemconstructor 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
ArcandFsCacheimports aligns with the codebase refactor that consolidates caching into a unifiedCache<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)))tonew_with_file_system(file_system, ...)correctly uses the new API that internally handles the cache creation and Arc wrapping, as seen insrc/lib.rslines 150-152.napi/patch.mjs (2)
3-3: LGTM: Variable rename for consistency.The rename from
fileUrltofilenameimproves 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.pnpand sets theUNRS_RESOLVER_YARN_PNPenvironment variable to enable PnP support. This aligns with the broader Yarn PnP integration described in the AI summary.Note: The static analysis warning about
writeFileSyncwith non-literal argument is a false positive -filenameis safely constructed fromimport.meta.urlin this build context.src/tests/full_specified.rs (2)
5-5: LGTM: Imports cleaned up for simplified resolver construction.Removal of
ArcandFsCacheimports is consistent with the codebase refactor that eliminates theFsCacheabstraction in favor of a unifiedCache<Fs>implementation.Also applies to: 8-8
31-32: LGTM: Both test functions updated consistently.The resolver construction is properly updated in both
test()andresolve_to_context()functions to use the newnew_with_file_systemAPI, 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
ArcandFsCacheimports aligns with the elimination of theFsCacheabstraction across the test suite.Also applies to: 8-8
23-24: LGTM: Resolver construction updated correctly.The change to use
new_with_file_systemdirectly with theMemoryFSinstance 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-genericResolutioncorrectly implements the consolidated resolver design with unifiedCache<Fs>type.src/tests/simple.rs (2)
68-68: LGTM: Import cleanup removes unused cache abstractions.The removal of
ArcandFsCacheimports 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>>)tonew_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.resolveRequestfor the 'is-even' module, ensuring compatibility with Yarn PnP resolution.justfile (2)
30-30: LGTM: Added documentation generation to readiness checks.Including
just docin 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) andcd fixtures/pnp && yarn testenhances 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
PackageJsonfrom imports is consistent with the refactoring that eliminates unused trait-based abstractions.
154-154: LGTM: Simplified resolver construction.Inlining
ResolveOptions::default()directly in theResolver::newcall eliminates an unnecessary intermediate variable and simplifies the code.
192-192: LGTM: Explicit cwd field assignment.Setting
cwd: Noneexplicitly 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_pnpcorrectly 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
ImportsExportsMapcorrectly replaces the Serde-specific type in theTestCasestruct.src/tests/exports_field.rs (2)
9-11: Import update looks correct.The new
ImportsExportsEntrytype replaces the removedImportsExportsSerdeEntryand 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: Missingextensions&condition_namesmay couple test to defaults.Unlike earlier tests, this resolver relies on default option values. If the defaults change (e.g.
extensionsstops 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_pnpfeature is enabled.
133-140: Good removal of feature gating.Removing the
#[cfg(feature = "fs_cache")]attribute makes thefrom_serde_json_errormethod always available, which aligns with the broader refactoring that removes thefs_cachefeature 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_jsoninstead ofPackageJsonSerde::raw_jsoncorrectly 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
TsConfigaligns with the broader refactoring removing trait abstractions.
151-151: Good migration from trait-based to concrete parsing.The consistent update from
TsConfigSerde::parsetoTsConfig::parseacross 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
FsCachewrapper andArcusage, along with the transition tonew_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
PackageJsonsignificantly 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
cwdfield 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_PNPenvironment 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
newmethod 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
CachedPathtype 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_iffor conditional compilation based on theyarn_pnpfeature 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 parameterAutomated checks indicate no residual references to the old cache APIs and no explicit generic instantiations of
ResolverGenericremain. However, please manually confirm the following:
- NAPI bindings (e.g. in your Node addon code) have been updated to call the new
ResolverGeneric::newandnew_with_file_systemsignatures correctly.- Any tests or example code that require a custom
FileSystemnow invokenew_with_file_systemrather than the removed generic constructor.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
There was a problem hiding this comment.
Caution
Changes requested ❌
Reviewed e7744de in 1 minute and 39 seconds. Click for details.
- Reviewed
128lines of code in6files - Skipped
1files when reviewing. - Skipped posting
5draft 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%<= threshold50%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%<= threshold50%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%<= threshold50%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 by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
Cargo.lockis excluded by!**/*.lockpnpm-lock.yamlis 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)



Important
Merge upstream changes from
oxc-project/oxc-resolver, adding Yarn PnP support, refactoring caching, and updating tests.This description was created by
for e7744de. You can customize this summary. It will automatically update as commits are pushed.
Summary by CodeRabbit
New Features
Bug Fixes
Refactor
Chores
Tests