• Draft comment:
  The result of json_strip_comments::strip(json) is discarded. Should assign its output to a variable and parse the stripped JSON to actually 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:
  Good change – using tsconfig.build() instead of an ad‑hoc expand_template_variables() improves clarity. Ensure that build() fully replicates the intended substitutions.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

• Draft comment:
  The call to json_strip_comments::strip(json) discards its result. Consider assigning the returned (comment‐stripped) string to a variable and using it for parsing.
• 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 build method’s substitution of the ${configDir} variable using normalize_with() appears correct, but please verify that trimming the leading '/' (with trim_start_matches('/')) is consistent with TS behavior.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  This comment is asking the PR author to verify consistency with TypeScript behavior, which falls under asking the author to confirm or double-check things. It doesn't provide a specific suggestion or point out a clear issue.

• Draft comment:
  In resolve_path_alias, the wildcard mapping logic selects the key with the longest prefix. Consider whether multiple matching patterns (or ties) need additional handling.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50%
  None

• Draft comment:
  Test cases for template variables and extended tsconfig files have been updated. Verify that expected outputs (such as 'src/foo.js') match the new substitution logic.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

• Draft comment:
  Typographical suggestion: It appears there's a tab character after the "extends": in the JSON property. For consistency and to avoid potential formatting issues, consider replacing the tab with a single space (or following the project's standard 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 JSON parsers handle both tabs and spaces fine. This is the kind of thing that should be handled by automated formatting tools or linters, not manual code review comments. Making comments about whitespace formatting creates noise in the PR review.
  The tab character could potentially cause issues in some JSON parsers or tools. Maybe the project has strict formatting standards that require spaces over tabs.
  If there are formatting requirements, they should be enforced by automated tools. Manual comments about whitespace are not a good use of code review.
  Delete this comment as it addresses a minor formatting issue that should be handled by automated tools rather than manual review comments.

• Draft comment:
  Minor formatting inconsistency: there's a tab character after the ':' in the JSON property on line 2. Consider replacing the tab with a standard space to maintain consistent 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 formatters or editors. This is a very minor formatting issue that doesn't affect functionality. The comment doesn't point out any logical or structural problems with the code.
  The tab character could theoretically cause issues with some JSON parsers or tools that expect strict formatting. Some teams might have strict formatting guidelines.
  JSON parsers generally handle both tabs and spaces fine, and if formatting is important to the team, they should be using automated formatters rather than manual review comments.
  This comment should be deleted as it addresses a trivial formatting issue that would be better handled by automated tools.

• Draft comment:
  There is an unexpected tab character after the colon in the "extends" property. Consider replacing the tab with a single space for consistency with standard JSON 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%
  This is a new file being added, so it is about changes. The issue is a minor formatting inconsistency. While it's technically correct, JSON formatting issues are usually handled by automated formatters and linters. The comment doesn't point out a functional issue or code quality problem that would impact the codebase.
  The tab character could potentially cause issues with some JSON parsers or tools. Also, maintaining consistent formatting helps with code readability.
  While consistency is good, this is a very minor formatting issue that would be better handled by automated tools rather than manual review comments.
  This comment should be removed as it addresses a trivial formatting issue that would be better handled by automated tools.

• Draft comment:
  The JSON file uses a tab character after the colon on line 2. It would be clearer to use a consistent spacing style (e.g., a single space) to avoid any confusion. This is a minor typographical issue.
• 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 code style consistency is generally good, this is a very minor formatting issue in a JSON file. JSON is whitespace-insensitive, and most editors/IDEs will automatically format JSON files. This seems like an overly pedantic comment that doesn't affect functionality or maintainability in any meaningful way.
  Perhaps inconsistent spacing could make the codebase look messy and affect readability for developers viewing raw files. Maybe there's a team style guide that specifically calls for consistent JSON formatting.
  Even if there are style preferences, this is too minor to warrant a PR comment. Most teams would handle this via automated formatting tools rather than manual review comments.
  This comment should be deleted as it's too minor and focuses on purely cosmetic formatting that doesn't impact code quality or functionality.

• Draft comment:
  Typo in comment: 'has defined it's own paths alias' should be 'has defined its own paths alias'.
• 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: 'has defined it's own paths alias' should be 'has defined its own paths alias'.
• 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: 'has defined it's own paths alias' should be 'has defined its own paths alias'.
• 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 comment: 'bases_base' should be 'paths_base' to accurately reflect the related property.
• 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 typo, fixing a minor typo in a comment is not a critical code change. The typo doesn't affect functionality and the meaning is still clear from context. According to the rules, we should not make purely informative comments or comments that are unimportant.
  The typo could potentially confuse future developers reading the code. Documentation accuracy is important for maintainability.
  While documentation accuracy matters, this is an extremely minor issue that doesn't meaningfully impact code understanding. The rules explicitly state not to make unimportant comments.
  This comment should be deleted as it addresses a trivial documentation issue that doesn't require immediate attention.

• Draft comment:
  Typo in documentation: 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 = 0% vs. threshold = 50%
  While the typo fix is technically correct, the line was only moved as part of a larger refactoring - the content itself wasn't changed. The rules state we should only comment on actual changes, not just moved code. Additionally, minor documentation typos are not critical issues requiring immediate fixes.
  The typo does impact readability slightly and would be easy to fix. Maybe we should keep minor improvements even on moved code?
  No, the rules are clear that we should only comment on actual changes, not moved code. The typo is minor and can be fixed in a future cleanup if needed.
  Delete this comment since it's about moved code rather than changed code, and addresses a minor documentation issue rather than a substantive problem.

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)

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

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

1-3: New JSON extension configuration.
This file extends from ../../tsconfig_template_variable3.json, promoting a modular approach to managing TypeScript configurations. Please verify that the referenced template exists and remains consistent with the project’s configuration strategy.

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

1-3: New JSON extension configuration.
The file extends from ../../tsconfig_template_variable2.json, which is in line with the broader modular configuration improvements. All looks good—just ensure that the inherited settings in the template are up-to-date.

fixtures/tsconfig/tsconfig.json (1)

3-5: Updated module path mapping.
The "ts-path" alias now correctly points to ["src/foo.js"], reflecting the reorganization of the project’s directory structure. Please double-check that the source file has been relocated accordingly and that all dependent modules reference the new path.

npm/package.json (1)

40-42: Addition of RISC-V target architecture.
The target "riscv64gc-unknown-linux-gnu" has been added to the napi.targets array. This change expands the supported platforms and is consistent with the new RISC-V build support introduced in the workflows. Please ensure that the CI/CD pipelines and build scripts are properly configured to handle this target.

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

1-3: New TypeScript configuration extension file.
This file extends from ../../tsconfig_template_variable1.json, which aligns with the recent restructuring (notably replacing the old tsconfig1.json). Its minimal structure is appropriate and helps keep configuration management modular.

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

1-3: Review of JSON Configuration Extension

This new file correctly extends the configuration from the provided template at "../../tsconfig_template_variable4.json". Please verify that the relative path accurately points to the intended template based on your repository structure.

fixtures/tsconfig/tsconfig_template_variable3.json (1)

1-9: Validation of TypeScript Compiler Options

The configuration properly sets "baseUrl" to "." and maps the module "foo" to "${configDir}/src/foo.js". Ensure that the variable "configDir" is defined in the appropriate context or that a build process substitutes it as expected.

fixtures/tsconfig/tsconfig_template_variable4.json (1)

1-9: Verification of Compiler Options and Module Paths

The file is well-formed and defines the compiler options using "${configDir}" as the base URL, with the "paths" mapping consistently resolving "foo" to "${configDir}/src/foo.js". Confirm that the ${configDir} substitution is supported and resolved correctly in your build process.

fixtures/tsconfig/tsconfig_template_variable2.json (1)

1-9: Assessment of Relative Path Mapping

This configuration sets "baseUrl" to "${configDir}" and maps "foo" to "./src/foo.js". Double-check that the relative path is intended to be resolved against the base URL and that it aligns with the overall project directory structure.

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

16-18: Update of Project Reference

The reference path in the "references" array has been updated to "../../paths_template_variable/tsconfig.json". Please verify that this change accurately reflects the restructured project layout and that the referenced configuration file exists in the specified location.

fixtures/tsconfig/tsconfig_template_variable1.json (1)

4-4: Update Path Mapping for "foo":
The path mapping for the "foo" module has been updated to reference "${configDir}/src/foo.js", aligning with the new directory structure. Please verify that all import statements and build processes have been adjusted accordingly.

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

5-5: Consistent Update for "foo" Path:
The mapping for "foo" has been modified to "${configDir}/src/foo.js", ensuring consistency with the updated project layout. Confirm that this change properly integrates with any composite builds or downstream reference requirements.

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

1-9: New Configuration for Base URL and Aliasing:
This new configuration file sets the baseUrl to "${configDir}" and provides a path alias "@/*" pointing to "./src/*". This addition supports a more flexible module resolution strategy. Double-check that any refactoring or import adjustments needed for this alias are in place across the project.

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

20-21: Updated Project Reference:
The reference now points to "../../paths_template_variable/tsconfig.json" instead of an older configuration file. This update aligns the project reference with the new path mapping conventions. Ensure that the referenced configuration file is correctly integrated with the project’s build process.

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

31-35: Bumped Release Plz Action Version:
The workflow now uses MarcoIeni/release-plz-action@7419a2cb1535b9c0e852b4dec626967baf65c022 (v0.5.102). Please verify that this updated action version is compatible with the rest of the workflow and that its new features or fixes support the intended release process without introducing regressions.

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

1-8: Well-structured TypeScript path mapping configuration

This configuration correctly sets up path resolution with a template variable for the base URL and maps @/* imports to the ./src/* directory. The configuration follows TypeScript standards and provides a clean way to organize imports.

package.json (2)

19-19: Appropriate use of caret versioning for dependency

Changing from fixed version "3.0.0-alpha.77" to caret version "^3.0.0-alpha.77" allows for compatible minor and patch updates while preventing breaking changes. This follows semantic versioning best practices.

---

26-26: Package manager version update

The update from pnpm@10.7.1 to pnpm@10.8.0 is a minor version change that likely includes improvements and bug fixes. This is a standard maintenance update.

src/tsconfig_serde.rs (2)

9-9: Clean import statement

The import is organized properly and appears to include all necessary components for the current implementation.

---

262-268: Improved parse method with simpler structure

The parse method has been simplified by removing the base_url normalization and paths_base handling logic. This refactoring aligns with the changes in the codebase where template variable handling has been moved to a dedicated build method in another file, improving separation of concerns.

src/tests/tsconfig_project_references.rs (2)

42-42: Updated path to reflect new directory structure

The test case has been correctly updated to use dir.join("src/foo.js") instead of dir.join("foo.js"), reflecting the move of JavaScript files to the src subdirectory. This change aligns with the updated path mappings in the TypeScript configuration.

---

65-65: Consistent path update in test expectations

This change is consistent with the previous update to use dir.join("src/foo.js") for the expected path, ensuring the test cases correctly validate the new directory structure.

src/fs_cache.rs (1)

192-192: Use of build() for tsconfig object creation
Replacing expand_template_variables() with build() centralizes the logic for template variable resolution. Please verify that downstream code correctly handles the new build() semantics—particularly for extended tsconfigs—and confirm that non-root configs won’t trigger unwanted substitutions.

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

85-92: Adding RISC-V target to the build matrix
These steps correctly install and set up the RISC-V cross-compiler. Note that you might also consider caching the downloaded packages or verifying that further dependencies aren’t needed if future steps rely on external libraries.

---

137-137: Ensuring artifact upload fails if none found
Setting if-no-files-found: error helps detect missing build artifacts early and prevents silent passing of a failing job. This is a robust improvement to the workflow.

src/tests/tsconfig_paths.rs (6)

14-14: Renaming test function for clarity
Renaming the function from a generic name to tsconfig_resolve clarifies its intention to specifically test resolution using tsconfig.

---

19-19: Updated expected path to src/foo.js
The test now expects the file within src/, aligning with the new directory layout for tested modules.

---

48-48: Referencing src/foo.js in test assertions
This update reflects the shifted directory structure. Ensure the fixture is correctly set up at src/foo.js to avoid broken path references.

---

136-136: Invoking .build() after .parse()
Calling .build() here finalizes and normalizes the tsconfig, replacing previous manual expansions. This is consistent with the new approach in src/tsconfig.rs.

---

166-166: Applying .build() for baseUrl resolution
Again, ensures that any template variable logic is handled in one place—good consistency.

---

197-197: Ensuring test coverage for .build()
Verifies that newly added logic in .build() is tested under various scenarios. Confirm that extended configurations also pass.

src/tsconfig.rs (12)

2-2: Importing Debug
Adding Debug ensures richer diagnostics and consistent trait bounds throughout the tsconfig types.

---

13-14: Introducing TEMPLATE_VARIABLE constant
Defining ${configDir} as a clear constant improves maintainability and consistency for future expansions or references.

---

23-24: Extending TsConfig and its associated type with Debug
Requiring Debug coverage makes these types more transparent for logging, testing, or error-handling scenarios.

---

83-83: Conditional logic for base_url()
This guard checks if baseUrl is present before populating from the extended tsconfig. Confirm that collisions between chained tsconfigs are resolved as expected.

---

131-133: Documentation for the new build() method
Providing a clear doc block clarifies how final expansions and directory calculations happen. This lowers confusion when reading or maintaining code.

---

137-142: build() early-return for non-root tsconfigs
If root() is false, it skips expansions—good approach to avoid double expansions or incorrect directory resolutions in extended configs.

---

145-151: Resolving baseUrl to absolute path
This logic joins paths with config_dir, handling the template variable. Ensure tests cover corner cases like leading/trailing slashes or Windows UNC paths.

---

154-154: Checking whether paths exist
This confirms the presence of a paths map before trying to apply transformations. Defensive checks reduce the risk of runtime errors.

---

155-158: Applying base_url as paths_base
This sets the correct base path to unify how path aliases resolve in the final config. Helps maintain consistency across nested references.

---

161-166: Template substitution in paths
Tying each path to config_dir ensures template variables like ${configDir} are expanded properly. Must confirm that trailing or leading slashes are also handled.

---

173-174: Completing the build() method
Method returns the updated tsconfig, finishing the scope of expansions. Straightforward flow.

---

176-181: Introducing substitute_template_variable
Isolating this logic keeps the code base more organized. This approach is more flexible if additional template variables appear in future.