• Draft comment:
  The result of json_strip_comments::strip(json) is discarded. Likely the stripped JSON should be used in serde_json::from_str to allow comments in JSON.
• 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.

• Draft comment:
  New RISC-V target 'riscv64gc-unknown-linux-gnu' is correctly added. Please double‐check if any additional cross‐compilation settings (e.g. in build scripts or CI) are needed for this target.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

• Draft comment:
  The build() method substitutes the ${configDir} placeholder correctly in baseUrl. Verify that both cases (with and without trailing slashes) work as intended, as this can affect absolute path resolution.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

• Draft comment:
  The call to json_strip_comments::strip(json) discards its result. If the intent is to clean the JSON input from comments, consider reassigning the stripped output to ensure comments don’t interfere with deserialization.
• 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.

• Draft comment:
  There is a commented out test case regarding reading the package.json.tsconfig field. If this test is no longer relevant, consider removing the commented code to keep the test suite clean.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

• Draft comment:
  The alias resolution logic (using star patterns) appears reasonable. Ensure that the selection of the best match (longest prefix/suffix) covers all edge cases in your test suite.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

• Draft comment:
  There is a tab character after the colon in the JSON property on line 2. For consistency with the rest of the codebase, consider replacing the tab with spaces.
• 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%
  This is a style/formatting issue in a JSON file. While it's technically correct that there's a tab character, this is something that should be handled by automated formatting tools or linters, not manual code review comments. The file will work fine either way, and this is a very minor formatting detail.
  Perhaps inconsistent formatting could lead to confusion or make the codebase look unprofessional. Maybe the project doesn't have automated formatting set up.
  Even if formatting is important, this kind of minor spacing issue should be handled by automated tools, not manual review comments. Manual comments should focus on more substantial issues.
  Delete this comment as it addresses a minor formatting issue that should be handled by automated tools rather than manual review.

• Draft comment:
  It appears that 'wasm32-wasip1-threads' may be a typographical error. If this target is intended to refer to the WASI environment (WebAssembly System Interface), consider correcting it to 'wasm32-wasi-threads' to follow the standard naming convention.
• 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.

• Draft comment:
  Typographical error: consider replacing "it's" with "its" in the comment starting on this line.
• 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.

• Draft comment:
  Typographical error: consider replacing "it's" with "its" in the comment on this line.
• 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.

• Draft comment:
  Typo in doc comment: Consider changing 'tests cases' to 'test cases' for clarity.
• 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 - "tests cases" is grammatically incorrect and should be "test cases" - it's a very minor documentation issue. The meaning is still clear despite the typo. The rules state we should only keep comments that require clear code changes, and documentation typos are generally not critical enough to warrant a comment.
  The typo could be seen as affecting code readability and professionalism. Documentation is part of the code and should be held to high standards.
  While documentation quality is important, this particular typo is extremely minor and doesn't impact understanding. The rules specifically say not to make purely informative comments or unimportant ones.
  The comment should be deleted as it points out a very minor documentation issue that doesn't materially impact code quality or understanding.

Reviewing files that changed from the base of the PR and between cc0f4fb and fced793.

• Cargo.lock is excluded by !**/*.lock
• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

• .github/workflows/release-napi.yml (2 hunks)
• .github/workflows/release-plz.yml (1 hunks)
• fixtures/tsconfig/cases/paths_template_variable/tsconfig.json (1 hunks)
• fixtures/tsconfig/cases/paths_template_variable/tsconfig1.json (0 hunks)
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_base_url1.json (1 hunks)
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_base_url2.json (1 hunks)
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_extends1.json (1 hunks)
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_extends2.json (1 hunks)
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_extends3.json (1 hunks)
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_extends4.json (1 hunks)
• fixtures/tsconfig/cases/project_references/app/tsconfig.json (1 hunks)
• fixtures/tsconfig/cases/project_references/app/tsconfig.nopaths.json (1 hunks)
• fixtures/tsconfig/tsconfig.json (1 hunks)
• fixtures/tsconfig/tsconfig_template_variable1.json (1 hunks)
• fixtures/tsconfig/tsconfig_template_variable2.json (1 hunks)
• fixtures/tsconfig/tsconfig_template_variable3.json (1 hunks)
• fixtures/tsconfig/tsconfig_template_variable4.json (1 hunks)
• napi/Cargo.toml (0 hunks)
• npm/package.json (1 hunks)
• package.json (1 hunks)
• src/fs_cache.rs (1 hunks)
• src/tests/tsconfig_paths.rs (6 hunks)
• src/tests/tsconfig_project_references.rs (2 hunks)
• src/tsconfig.rs (5 hunks)
• src/tsconfig_serde.rs (1 hunks)

• fixtures/tsconfig/cases/paths_template_variable/tsconfig1.json
• napi/Cargo.toml

• GitHub Check: Test (windows-latest)

npm/package.json (1)

41-41: Addition of RISC-V Target.
The new target "riscv64gc-unknown-linux-gnu" is added appropriately to the napi.targets array. Please ensure that your build and toolchain configurations support this target.

.github/workflows/release-plz.yml (1)

31-31: Release Action Version Update.
The update of the release-plz-action from an older version to v0.5.102 appears to be a straightforward version bump. Verify that the new version maintains backward compatibility with your workflow and that no breaking changes are introduced.

package.json (2)

19-19: Dependency Version Update for @napi-rs/cli.
Changing the version from a fixed version to the caret range "^3.0.0-alpha.77" allows for automatic patch and minor updates. Please confirm that there are no unintended breaking changes from newer versions in that release line.

---

26-26: Updated Package Manager Version.
The update to "pnpm@10.8.0" should enable access to the latest features and fixes. Verify that this new version is compatible with your project’s dependency management and build pipelines.

.github/workflows/release-napi.yml (1)

137-137: Artifact Upload Enforcement.
The addition of if-no-files-found: error strengthens the artifact upload step by enforcing an error if expected files are missing. Confirm that this configuration does not inadvertently break the build in scenarios where artifacts might legitimately be absent.

fixtures/tsconfig/cases/paths_template_variable/tsconfig_extends1.json (1)

1-3: Valid Minimal JSON Extension Configuration

This new configuration file cleanly extends the template (../../tsconfig_template_variable1.json) as intended. The structure is simple and adheres to the project’s configuration standards.

fixtures/tsconfig/cases/paths_template_variable/tsconfig_extends3.json (1)

1-3: Correct Inheritance from Base Configuration

This file properly extends ../../tsconfig_template_variable3.json with a minimal JSON structure, ensuring that all necessary compiler options are inherited.

fixtures/tsconfig/tsconfig.json (1)

1-8: Updated Path Mapping for Module Resolution

The update changes the path mapping for the "ts-path" alias from the generic "foo.js" to the more specific "src/foo.js", which aligns with the new directory structure. This adjustment will help TypeScript resolve modules correctly.

fixtures/tsconfig/tsconfig_template_variable2.json (1)

1-8: Accurate Template Configuration for Compiler Options

This new configuration file establishes a clear base URL using ${configDir} and maps the "foo" module to "./src/foo.js". The configuration is concise and consistent with the overall changes to the TypeScript project structure.

fixtures/tsconfig/cases/paths_template_variable/tsconfig_base_url1.json (1)

1-9: Valid Base URL and Path Mapping

This configuration correctly sets the baseUrl to ${configDir} and maps the alias @/* to ./src/*. Everything appears consistent and suitable for module resolution.

fixtures/tsconfig/tsconfig_template_variable1.json (1)

1-8: Updated Module Path Mapping

The path mapping for "foo" has been updated to "${configDir}/src/foo.js", which reflects the new directory structure. This change is clear and consistent with the other configuration updates.

fixtures/tsconfig/cases/project_references/app/tsconfig.json (1)

1-24: Corrected Project Reference

The reference path update to "../../paths_template_variable/tsconfig.json" is appropriate and aligns with the new file organization. Please ensure that downstream builds and references resolve this updated path correctly.

fixtures/tsconfig/cases/paths_template_variable/tsconfig.json (1)

1-9: Consistent Paths Configuration

The update modifying the "foo" mapping to "${configDir}/src/foo.js" is consistent with the changes made in related configuration files. The JSON overall is properly structured.

fixtures/tsconfig/cases/paths_template_variable/tsconfig_base_url2.json (1)

1-8: LGTM: Well-structured TypeScript path configuration

This configuration properly sets up a path alias mapping for TypeScript, using a template variable ${configDir}/ for dynamic resolution based on the configuration directory. The paths mapping for @/* to ./src/* follows common patterns for module aliasing.

fixtures/tsconfig/tsconfig_template_variable3.json (1)

1-8: LGTM: Proper template variable usage in paths mapping

This TypeScript configuration correctly sets up a module alias for "foo" that points to a file using the ${configDir} template variable. This approach allows for dynamic path resolution based on the configuration directory context.

fixtures/tsconfig/cases/project_references/app/tsconfig.nopaths.json (1)

17-17: Path reference updated correctly

The path reference has been updated from tsconfig2.json to tsconfig.json, which appears to be an intentional correction to ensure consistent configuration referencing across project files.

fixtures/tsconfig/tsconfig_template_variable4.json (1)

1-8: LGTM: Appropriate template variable configuration

This configuration properly uses the ${configDir} template variable both in the baseUrl and in the paths mapping. Note that unlike tsconfig_template_variable3.json, this file has baseUrl set directly to the template variable without additional path segments.

src/tsconfig_serde.rs (2)

9-9: Updated imports to support refactored template variable handling

The imports have been updated to match the refactored implementation of template variable handling elsewhere in the codebase.

---

262-268: LGTM: Simplified parse method as part of template variable handling refactoring

The parse method has been simplified to focus on its core responsibilities: parsing JSON and setting basic properties. The previously included logic for handling base_url normalization and paths_base assignment has been moved to a new build method in the TsConfig trait implementation elsewhere.

This separation of concerns improves the code structure by centralizing template variable resolution and path handling in dedicated methods.

src/tests/tsconfig_project_references.rs (2)

42-42: New path reference looks consistent.

Switching from foo.js to src/foo.js keeps the test in sync with the updated directory structure. No issues found.

---

65-65: Confirmed path alignment with updated fixture.

Using src/foo.js here mirrors the change above. This appears correct for the modified directory layout.

src/fs_cache.rs (1)

192-192:

❓ Verification inconclusive

Ensure the new build() call correctly handles template variables.

Replacing the previous template expansion with tsconfig.build() centralizes the finalization logic. Please confirm that all references to expand_template_variables() have been removed or replaced.

---

🏁 Script executed:

#!/bin/bash
# Searching the codebase for any references to the old method
rg 'expand_template_variables'

Length of output: 30

---

Action: Verify Template Variable Handling

The updated code now uses tsconfig.build() to centralize template variable processing. Our initial search for expand_template_variables produced no results, suggesting that references have been removed. However, please perform a manual verification to ensure that all aspects of template variable expansion are indeed handled correctly within the new build logic.

src/tests/tsconfig_paths.rs (9)

14-14: Function rename improves clarity.

Renaming from tsconfig to tsconfig_resolve clarifies the intention. This change appears beneficial for readability.

---

19-19: Updated path reference.

Adopting f.join("src/foo.js") aligns with the new source directory structure.

---

48-48: Confirm path usage in non-used tsconfig.

Here, Ok(f.join("src/foo.js")) matches the shift to a src/ subdirectory. Looks correct.

---

136-136: Added .build() call for finalizing tsconfig.

This ensures template variable substitution and base URL resolution happen before using the tsconfig. No issues noted.

---

166-166: Consistent .build() usage.

Same reasoning as above: finalizing config after parse. This is coherent and appears correct.

---

197-197: Applying .build() to unify config logic.

Ensures that references, paths, and base URL are resolved in one place. Looks good.

---

249-249: New test expectation referencing src/foo.js.

This test entry now reflects the moved file location. No concerns raised.

---

251-256: Maintaining consistent path resolution in extended configurations.

All these entries target src/foo.js, which aligns with the updated directory layout and template variable logic.

---

257-260: Further demonstration of foo.js relocation.

These references show the same adjusted path. Approved for consistency.

src/tsconfig.rs (6)

2-2: Debug import aligns with trait changes.

Enabling Debug usage for TsConfig and its compiler options is beneficial for diagnostic logging.

---

13-13: New constant for template substitution.

Defining TEMPLATE_VARIABLE centralizes the placeholder and prevents magic strings. Looks clean.

---

23-24: Adding Debug to the trait and its associated type.

This extension facilitates easier debugging of tsconfig structures. Approved.

---

83-83: Guarding baseUrl assignment.

The new condition ensures existing base_url isn’t overwritten. This is a sensible fallback approach.

---

90-96: Conditional logic for paths inheritance.

Only sets paths and paths_base if not already provided, improving clarity in tsconfig merging.

---

131-189: Introducing build() and template resolution.

This method unifies final steps for root tsconfig, substituting ${configDir} and consolidating path logic. It’s a clean and maintainable design.

• Draft comment:
  The call to json_strip_comments::strip(json) discards its result. To properly remove comments before parsing, assign the result to a variable and pass that to serde_json::from_str. This ensures that comments are stripped as intended.
• 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.

• Draft comment:
  The output of json_strip_comments::strip(json) is discarded. It looks like the intention is to remove comments from the JSON before deserialization. Consider capturing and using its return value (e.g. assigning to a local variable) so that the parsed JSON is comment‐free.
• 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.

• Draft comment:
  In the build() method, the substitution of the '{configDir}' template variable for baseUrl uses trim_start_matches('/'). A brief comment explaining the handling of leading slashes and how relative paths are expected to be formatted would improve clarity.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  The comment is asking for an explanation to be added to the code, which is not allowed as it falls under asking the author to explain or clarify their intention. The comment does not provide a specific code suggestion or point out a potential issue with the code itself.

• Draft comment:
  The wildcard matching in resolve_path_alias selects the best key using the longest prefix and suffix lengths. Adding a comment that explains the rationale (e.g. handling multiple wildcard patterns, choosing the most specific match) would help future maintainers.
• 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.

• Draft comment:
  It appears that there's a tab character between the key "extends" and its value. While JSON allows any whitespace, it's more conventional to use spaces for consistency. Consider replacing the tab with spaces to adhere to the project's formatting standards.
• 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 tab character, this is purely a formatting issue. JSON spec allows any whitespace. Most editors and formatters would automatically handle this. This isn't a logic or functionality issue. The comment doesn't indicate any actual problems that need fixing.
  The inconsistent use of tabs vs spaces could lead to formatting inconsistencies across the codebase if left unchecked. Some teams do care about strict formatting standards.
  However, this is exactly the kind of minor formatting issue that should be handled by automated formatters or linters, not manual code review comments. It doesn't affect functionality.
  Delete this comment as it addresses a trivial formatting issue that should be handled by automated tools, not code review.

• Draft comment:
  Typographical note: There is a tab character after the colon in line 2. Consider replacing it with a space for consistency in formatting.
• 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 tab character, formatting issues in JSON files are typically handled automatically by code formatters or IDE settings. This is a very minor formatting issue that doesn't affect functionality. The rules specifically mention not making purely informative comments or obvious/unimportant ones.
  The inconsistent use of tabs vs spaces could potentially indicate a deeper configuration issue or could propagate through other files if copied.
  JSON formatting is well-standardized and most development environments will automatically handle this. This is too minor to warrant a PR comment.
  This comment should be removed as it addresses a trivial formatting issue that doesn't require manual intervention.

• Draft comment:
  There appears to be a tab between the colon and the value in the extends property. Consider replacing the tab with a single space to maintain consistency in formatting.
• 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 tab character, this is a very minor formatting issue. Most projects would handle this automatically with prettier/eslint. The change doesn't affect functionality. The comment feels overly pedantic.
  The tab inconsistency could propagate if other developers copy this file as a template. Inconsistent formatting can make diffs harder to read.
  While formatting consistency is good, this is exactly the kind of thing that should be handled by automated formatting tools, not code review comments. It's too minor to warrant manual intervention.
  Delete this comment as it's too minor and would typically be handled by automated formatting tools.

• Draft comment:
  Typographical error: In the comment on line 9, 'it's own' should be changed to 'its own'.
• 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.

• Draft comment:
  Typographical error: In the comment on line 79, 'it's own' should be 'its own'.
• 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.

• Draft comment:
  Typographical error: In the comment on line 139, 'it's own' should be corrected to 'its own'.
• 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.

• Draft comment:
  Typo in comment: Consider changing 'tests cases' to 'test cases' for grammatical clarity.
• 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 (it is a grammatical error), it's a very minor documentation issue. The rules state not to make purely informative comments or comments that are obvious/unimportant. Documentation typos, unless they make the meaning unclear, fall into this category.
  The typo could potentially cause confusion for non-native English speakers. Also, maintaining high quality documentation is important for project maintainability.
  While documentation quality is important, this particular typo does not impact understanding of the code or documentation. The meaning is still clear despite the minor grammatical error.
  The comment should be deleted as it violates the rule about not making purely informative comments or comments about unimportant issues.

• Draft comment:
  The result of json_strip_comments::strip(json) is discarded. You likely meant to pass the stripped JSON to serde_json::from_str to properly remove comments.
• 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.

• Draft comment:
  The implementation of substitute_template_variable only replaces the template if it appears as a prefix. Consider whether you want a more robust substitution (or document the limitation).
• 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%
  The code already documents this limitation in the comments. The limitation appears intentional based on test cases. The comment suggests either changing the implementation or documenting the limitation - but the limitation is already documented. The comment isn't really actionable since this appears to be working as intended.
  The comment raises a valid technical point about a potential edge case. Maybe there are real-world cases where ${configDir} appears mid-path that we're missing?
  The code comment explicitly states this matches the test cases, suggesting this is the intended behavior. If mid-path substitution was needed, it would be covered by tests.
  Delete the comment since the limitation is already documented in the code comments and appears to be intentional based on test coverage.

• Draft comment:
  The result of json_strip_comments::strip is discarded. Use its output for parsing to properly remove comments.
• 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.

• Draft comment:
  Consider additional trimming of whitespace after substituting the ${configDir} variable.
• Reason this comment was not posted:
  Confidence changes required: 30% <= threshold 50%
  None

• Draft comment:
  Verify if the package version '0.0.0' is intended for a private package; ensure proper version bump before publishing.
• Reason this comment was not posted:
  Confidence changes required: 30% <= threshold 50%
  None

• Draft comment:
  Typographical error: In the comment, consider changing "it's own paths alias" to "its own paths alias" to properly use the possessive form.
• 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.

• Draft comment:
  Typographical error: In the comment, consider changing "it's own paths alias" to "its own paths alias" to correctly denote possession.
• 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.

• Draft comment:
  Typographical error: In the 'substitute_template_variable' function's comment, please change "All tests cases are just a head replacement of ${configDir}" to "All test cases are just a head replacement of ${configDir}".
• 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 typo is real, it's in a comment and doesn't affect functionality. The rules say to only keep comments that require code changes. Comment typos are not important enough to warrant a PR comment. This feels like the kind of nitpick that just adds noise to the review.
  The typo could indicate a lack of attention to detail that might extend to the code. Documentation quality is important for maintainability.
  While documentation quality matters, this is an extremely minor issue that doesn't impact understanding. The rules explicitly say not to make unimportant comments.
  Delete this comment as it's too minor and doesn't require a code change.

Reviewing files that changed from the base of the PR and between fced793 and 75623f9.

• Cargo.lock is excluded by !**/*.lock
• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

• .github/workflows/release-napi.yml (2 hunks)
• .github/workflows/release-plz.yml (1 hunks)
• fixtures/tsconfig/cases/extends-paths/tsconfig.base.json (1 hunks)
• fixtures/tsconfig/cases/extends-paths/tsconfig.json (1 hunks)
• fixtures/tsconfig/cases/paths_template_variable/tsconfig.json (1 hunks)
• fixtures/tsconfig/cases/paths_template_variable/tsconfig1.json (0 hunks)
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_base_url1.json (1 hunks)
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_base_url2.json (1 hunks)
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_extends1.json (1 hunks)
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_extends2.json (1 hunks)
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_extends3.json (1 hunks)
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_extends4.json (1 hunks)
• fixtures/tsconfig/cases/project_references/app/tsconfig.json (1 hunks)
• fixtures/tsconfig/cases/project_references/app/tsconfig.nopaths.json (1 hunks)
• fixtures/tsconfig/tsconfig.json (1 hunks)
• fixtures/tsconfig/tsconfig_template_variable1.json (1 hunks)
• fixtures/tsconfig/tsconfig_template_variable2.json (1 hunks)
• fixtures/tsconfig/tsconfig_template_variable3.json (1 hunks)
• fixtures/tsconfig/tsconfig_template_variable4.json (1 hunks)
• napi/Cargo.toml (0 hunks)
• npm/package.json (1 hunks)
• package.json (1 hunks)
• src/fs_cache.rs (1 hunks)
• src/tests/tsconfig_paths.rs (6 hunks)
• src/tests/tsconfig_project_references.rs (2 hunks)
• src/tsconfig.rs (5 hunks)
• src/tsconfig_serde.rs (1 hunks)

• napi/Cargo.toml
• fixtures/tsconfig/cases/paths_template_variable/tsconfig1.json

• fixtures/tsconfig/cases/extends-paths/tsconfig.base.json
• fixtures/tsconfig/cases/extends-paths/tsconfig.json

• fixtures/tsconfig/cases/paths_template_variable/tsconfig_extends1.json
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_extends2.json
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_extends3.json
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_extends4.json
• .github/workflows/release-plz.yml
• fixtures/tsconfig/tsconfig_template_variable3.json
• fixtures/tsconfig/tsconfig.json
• fixtures/tsconfig/tsconfig_template_variable4.json
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_base_url1.json
• src/tsconfig_serde.rs
• fixtures/tsconfig/cases/project_references/app/tsconfig.nopaths.json
• npm/package.json
• fixtures/tsconfig/cases/paths_template_variable/tsconfig_base_url2.json
• fixtures/tsconfig/cases/paths_template_variable/tsconfig.json
• fixtures/tsconfig/tsconfig_template_variable2.json
• package.json
• fixtures/tsconfig/tsconfig_template_variable1.json
• fixtures/tsconfig/cases/project_references/app/tsconfig.json
• src/tests/tsconfig_project_references.rs
• src/fs_cache.rs

.github/workflows/release-napi.yml (1)

137-137: Enhanced Artifact Upload Check
Adding if-no-files-found: error in the artifact upload step is a beneficial improvement that ensures the workflow fails early when expected artifacts are missing, thereby preventing silent failures.

src/tests/tsconfig_paths.rs (7)

14-14: Function name changed from tsconfig to tsconfig_resolve improves clarity.

The renamed function better reflects its actual purpose, which is to test path resolution using tsconfig settings.

---

19-19: Path update to accommodate the new directory structure.

The expected path is now correctly pointing to src/foo.js instead of foo.js, which aligns with the changes in the directory structure.

---

48-48: Path update for consistency with new directory structure.

Similar to the earlier path changes, this update ensures all expected paths correctly point to the new src/foo.js location.

---

136-136: Added .build() call to correctly process the tsconfig.

This change is necessary to utilize the new build method from the TsConfig trait, which handles template variable substitution and path normalization.

---

166-166: Added .build() call for consistency with updated processing flow.

Similar to the earlier change, this ensures the tsconfig is properly processed before being used in tests.

---

197-197: Added .build() call for proper tsconfig initialization.

This change maintains consistency with the updated processing flow throughout the test suite.

---

250-260: Updated test paths to reflect the new directory structure.

The test data for test_template_variable has been appropriately updated to use src/foo.js instead of foo.js, ensuring tests accurately validate the new path structure.

src/tsconfig.rs (6)

2-2: Added Debug trait import to support new trait bounds.

The addition of Debug for improved diagnostics is a good practice that will help with troubleshooting and logging.

---

13-14: Added constant for the template variable pattern.

Defining TEMPLATE_VARIABLE as a constant rather than using string literals improves maintainability and reduces the risk of typos when checking for the template pattern.

---

23-24: Added Debug trait bounds to TsConfig and CompilerOptions.

This change enhances the diagnostics capabilities for the entire configuration system, making it easier to debug configuration issues.

---

90-96: Simplified logic for setting paths_base in extend_tsconfig.

The refactored logic provides a cleaner approach to setting paths_base and paths when extending configs, improving readability and maintainability.

---

137-174: Added new build method to handle template substitution and path normalization.

This is an excellent addition that centralizes the logic for:

1. Processing the ${configDir} template variable
2. Normalizing paths_base and baseUrl
3. Ensuring consistent path resolution across the configuration

The implementation properly handles both absolute and relative paths, which is crucial for correct path resolution.

---

183-188: Added helper method for template variable substitution.

The new substitute_template_variable method provides a clean implementation for handling template substitution, promoting code reuse and consistency across the codebase.

• Draft comment:
  Authors field updated, but the PR mentions adding RISC-V support. Ensure the necessary target configuration is included elsewhere.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  The comment is asking the author to ensure that the necessary target configuration is included, which is against the rules. It is not making a specific code suggestion or pointing out a specific issue with the code. Therefore, it should be removed.

• Draft comment:
  Author metadata updated. However, the diff only shows this change and no modifications related to the RISC-V target support as described in the PR. Verify that the upstream merge indeed includes the intended riscv support.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  The comment is asking the author to verify if the upstream merge includes the intended RISC-V support, which is against the rules as it asks for confirmation of intention. It does not provide a specific code suggestion or ask for a specific test to be written.

• Draft comment:
  Typo: There is an inconsistency in the author's contact information formatting. The email domain is written as '1stg.me' (all lowercase) while the URL is '1stG.me' (with an uppercase 'G'). Please standardize the casing for consistency.
• 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%
  This is a very minor stylistic issue about casing in the author's personal URL. The author likely intentionally uses different casing in their URL as part of their branding. This isn't a code quality issue, doesn't affect functionality, and is purely about personal preference in how someone represents their contact information.
  Maybe inconsistent casing could cause issues in some contexts? Maybe there's a Cargo.toml standard for author information formatting?
  The casing difference is in a URL which is likely intentional branding, and there's no standard requiring consistent casing in author URLs. This is too minor to warrant a comment.
  Delete this comment as it's purely stylistic, doesn't affect functionality, and relates to personal branding choices in contact information.

• Draft comment:
  The result of json_strip_comments::strip(json) is discarded. If the intent is to remove comments before parsing, its returned value should be used (e.g. assign to a new string and parse that).
• 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.

• Draft comment:
  Consider clarifying the behavior when no path alias key exactly matches and a star pattern is used. Ensure that joining base paths and chaining the base_url_iter is the intended resolution order.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50%
  None

• Draft comment:
  Consider clarifying the baseUrl substitution logic. The use of strip_prefix on the base_url assumes an exact match with '${configDir}' but may miss trailing slash variations. Document or handle such edge cases.
• 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%
  The code actually handles trailing slashes gracefully:
• If there's no template variable, it normalizes the path
• If there is a template variable, it explicitly trims any leading slashes after substitution
• The constant is clearly defined at the top of the file
• The behavior seems intentional and well-handled
  I could be missing some edge cases that aren't obvious. The comment author may have encountered specific problematic cases.
  The code explicitly handles trailing slashes and has clear fallback behavior. The implementation looks robust and intentional.
  The comment should be deleted as the code already handles trailing slash variations appropriately and the implementation is clear.

• Draft comment:
  The call to json_strip_comments::strip(json) discards its result. Consider handling or checking errors from stripping comments to avoid unexpected parsing issues.
• 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.

• Draft comment:
  The unsafe block in 'replace_extension' lacks a safety explanation. Please document the invariants that justify using from_encoded_bytes_unchecked.
• 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.

• Draft comment:
  In resolve_path_alias, the matching logic for wildcard keys is non-obvious. Consider adding inline comments to explain how the longest prefix/suffix rule is determined for alias substitution.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50%
  None

• Draft comment:
  Typographical issue: The header reads "# This file is automatically @generated by Cargo." Consider removing the '@' to standardize it as "# This file is automatically generated by Cargo."
• 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.

• Draft comment:
  Grammar suggestion: In the comment on line 54, instead of saying "both pedantic and nursery is enabled", it should be "both pedantic and nursery are enabled" for grammatical consistency.
• 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.

• Draft comment:
  Grammar suggestion: In the comment on line 55, consider replacing "does not make sense" with "do not make sense" to match the plural subject, improving readability.
• 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.

• Draft comment:
  Typographical error: please change "it's" to "its" in the comment at line 9 to correctly indicate possession.
• 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.

• Draft comment:
  Typographical error: please change "it's" to "its" in the comment at line 79 to correctly indicate possession.
• 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.

• Draft comment:
  Typo: In the note for the substitute_template_variable method, consider changing "All tests cases" to "All test cases" for grammatical correctness.
• 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 grammar, it's a very minor documentation issue. The meaning is still clear even with the typo. According to the rules, we should not make purely informative comments or comments that are obvious/unimportant. Documentation typos generally fall into this category unless they significantly impact understanding.
  The typo could be seen as affecting code quality since it's in public documentation. Documentation quality is important for API consumers.
  While documentation quality matters, this particular typo is extremely minor and doesn't impact understanding. The rules specifically say not to make unimportant comments.
  The comment should be deleted as it points out an unimportant documentation typo that doesn't impact understanding.

• Draft comment:
  In the build() function, the substitution logic for the baseUrl uses strip_prefix on the TEMPLATE_VARIABLE. Confirm that trimming the leading '/' from the stripped path meets all edge cases (e.g. when there is no leading slash).
• Reason this comment was not posted:
  Comment looked like it was already resolved.

• Draft comment:
  The resolve_path_alias function uses a loop to select a key with the longest prefix match. Consider verifying if overlapping alias patterns are handled as expected; the current logic may be brittle if multiple patterns match.
• 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.

• Draft comment:
  In build(), after setting paths_base and substituting template variables in paths, ensure that empty paths_base is handled consistently. Double-check if an empty OS string could trigger unintended behavior.
• 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.

• Draft comment:
  In the parse() method, json_strip_comments is called but its result is discarded. Consider using the stripped JSON text for parsing to improve robustness if comments interfere with deserialization.
• 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.

• Draft comment:
  The call to json_strip_comments::strip(json) discards the stripped output. Consider capturing and using the returned (comment‐free) JSON string before parsing, to properly remove comments.
• 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.

• Draft comment:
  Ensure that the replacement logic for '*' in resolve_path_alias safely handles edge cases. Verify that longest_prefix_length and longest_suffix_length correctly partition the specifier string to avoid panics.
• 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.

• Draft comment:
  The logic for canonicalizing symlinks using OnceLock and an atomic counter looks solid; ensure that the fallback (debug_assert branch) covers all unexpected cases. No change is required if tests pass.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

• Draft comment:
  The build method resolves baseUrl and paths_base effectively. Verify that substituting the template variable using strip_prefix is adequate for all valid tsconfig formats.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

• Draft comment:
  Typo in comment: Consider changing 'naming things are hard' to 'naming things is hard' for grammatical correctness.
• 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.

• Draft comment:
  Typographical suggestion: Change 'both pedantic and nursery is enabled' to 'both pedantic and nursery are enabled' to match the plural subject.
• 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.

• Draft comment:
  Typographical note: In the phrase 'either false positives, chaotic, or does not make sense', consider changing 'does not make sense' to 'do not make sense' to maintain subject-verb agreement.
• 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.

• Draft comment:
  Typo detected: The target 'wasm32-wasip1-threads' looks like it might be a typo. Did you mean 'wasm32-wasi-threads'?
• 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.

• Draft comment:
  Typographical error: Change "it's own paths alias" to "its own paths alias" for proper possessive use.
• 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.

• Draft comment:
  Typographical error: Change "has defined it's own paths alias" to "has defined its own paths alias" to correctly express possession.
• 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.

• Draft comment:
  Typographical error: In the doc comment for 'substitute_template_variable', 'All tests cases' should be corrected to 'All test cases'.
• 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 grammatical suggestion is technically correct, the doc comment was not actually changed in this PR - it was just moved from one location to another. The rules state we should only comment on actual changes, not pre-existing code. Additionally, this is a very minor grammatical issue that doesn't impact code functionality.
  The grammar error could make the documentation slightly less professional. Maybe it's worth fixing while we're touching this code anyway?
  No - the rules are clear that we should only comment on actual changes. Moving code without modifying it doesn't count as a change that warrants review comments.
  Delete this comment since it refers to a pre-existing grammatical issue in code that was only moved, not modified.