test: add imports field chain resolution test cases

[stormslowly]

Summary

Add two test cases for imports field resolution, which will be used for regression testing in other RP.

test_imports_chain (currently ignored)

Chained imports resolution: #a → #b → ./the.js

{ "imports": { "#a": "#b", "#b": "./the.js" } }

Runtime	Result
enhanced-resolve	✅ Resolved → the.js
Node.js v20 (ESM)	❌ ERR_MODULE_NOT_FOUND — treats #b as a bare package specifier
Node.js v20 (CJS)	❌ MODULE_NOT_FOUND — same reason
rspack-resolver	❌ NotFound("#b") — chain resolution not yet supported

The problem is that the error message is confusing; it tells user #b not defined, but it's shown in imports.

test_imports_chain_to_other_package

Imports resolving to a bare specifier: #c → "c" → node_modules/c/index.js

{ "imports": { "#c": "c" } }

Runtime	Result
enhanced-resolve	✅ Resolved → node_modules/c/index.js
Node.js v20 (ESM)	✅ Resolved → node_modules/c/index.js
Node.js v20 (CJS)	✅ Resolved → node_modules/c/index.js
rspack-resolver	✅ Resolved → node_modules/c/index.js

Test plan

• cargo test test_imports_chain_to_other_package passes
• cargo test test_imports_chain currently fails (expected — chain resolution not yet supported)

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the test suite for rspack-resolver by adding specific test cases for the imports field resolution. The new tests aim to identify current limitations and confirm expected behavior, particularly regarding chained imports and resolution to bare specifiers, thereby guiding future development towards feature parity with enhanced-resolve and Node.js.

Highlights

• New Test Cases for Imports Field Resolution: Added two new test cases to evaluate the imports field resolution behavior in rspack-resolver.
• Chained Imports Resolution: Introduced test_imports_chain to test chained imports resolution (e.g., #a → #b → ./the.js), which is an enhanced-resolve specific behavior. This test is currently expected to fail as the feature is not yet supported in rspack-resolver.
• Imports to Bare Specifiers: Added test_imports_chain_to_other_package to verify imports resolving to a bare specifier (e.g., #c → "c" → node_modules/c/index.js), which is consistently supported across enhanced-resolve, Node.js, and rspack-resolver.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request adds two test cases for imports field resolution. One test for chained imports is expected to fail as the feature is not yet supported, which is a good approach. The other test for resolving to a bare specifier seems correct. I have one minor suggestion for consistency.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 78d5915b69

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[Copilot]

Pull request overview

Adds additional regression tests around imports field resolution behavior in the resolver test suite, focusing on “chained” # imports and imports that map to a bare specifier.

Changes:

• Add test_imports_chain intended to cover chained imports mappings (#a -> #b -> ./the.js).
• Add test_imports_chain_to_other_package to cover imports mapping to a bare package specifier (#c -> c).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[codspeed-hq]

Merging this PR will not alter performance

✅ 12 untouched benchmarks

---

_{Comparing chore/add_import_chain_test_case (1e96075) with main (b36ec51)¹}

Footnotes

1. No successful run was found on main (3edc3cb) during the generation of this report, so b36ec51 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩