Skip to content

Conversation

@martinjlowm
Copy link

Add tap(), tapAsync(), and tapPromise() methods to HookMap and QueriedHookMap classes for webpack compatibility. These methods delegate to for(key).tap/tapAsync/tapPromise, matching the API provided by webpack's tapable library.

This enables webpack plugins that use patterns like hookMap.tap(key, "name", fn) to work correctly with rspack.

Add tap(), tapAsync(), and tapPromise() methods to HookMap and
QueriedHookMap classes for webpack compatibility. These methods
delegate to for(key).tap/tapAsync/tapPromise, matching the API
provided by webpack's tapable library.

This enables webpack plugins that use patterns like
hookMap.tap(key, "name", fn) to work correctly with rspack.
@gemini-code-assist
Copy link

Summary of Changes

Hello @martinjlowm, I'm Gemini Code Assist1! 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 HookMap and QueriedHookMap classes by introducing tap, tapAsync, and tapPromise convenience methods. These additions are crucial for improving compatibility with existing webpack plugins, allowing them to function correctly within the rspack ecosystem by aligning with the tapable library's API for hook registration.

Highlights

  • New HookMap Tap Methods: Added tap(), tapAsync(), and tapPromise() methods to the HookMap class, allowing for direct tapping of hooks by key.
  • New QueriedHookMap Tap Methods: Implemented tap(), tapAsync(), and tapPromise() methods on the QueriedHookMap class, mirroring the functionality added to HookMap.
  • Webpack Compatibility: These new methods delegate to for(key).tap/tapAsync/tapPromise, matching the API provided by webpack's tapable library to improve compatibility with webpack plugins.
  • New Unit Tests: A new test file, test/HookMap.test.js, was added to thoroughly test the new tap convenience methods and existing HookMap functionalities like for, get, and isUsed.

🧠 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.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

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.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

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

Code Review

This pull request adds tap, tapAsync, and tapPromise convenience methods to HookMap and QueriedHookMap to improve compatibility with webpack plugins. The changes to HookMap are well-implemented and include a comprehensive new test suite. However, the implementation of these methods on QueriedHookMap introduces a design inconsistency by bypassing the class's stageRange logic. My review includes a comment to address this issue by suggesting the removal of these methods from QueriedHookMap.

src/index.ts Outdated
Comment on lines 1121 to 1143
tap(
key: HookMapKey,
options: Options<ExtractHookAdditionalOptions<H>>,
fn: Fn<ExtractHookArgs<H>, ExtractHookReturn<H>>,
) {
return this.hookMap.for(key).tap(options, fn);
}

tapAsync(
key: HookMapKey,
options: Options<ExtractHookAdditionalOptions<H>>,
fn: FnAsync<ExtractHookArgs<H>, ExtractHookReturn<H>>,
) {
return this.hookMap.for(key).tapAsync(options, fn);
}

tapPromise(
key: HookMapKey,
options: Options<ExtractHookAdditionalOptions<H>>,
fn: FnPromise<ExtractHookArgs<H>, ExtractHookReturn<H>>,
) {
return this.hookMap.for(key).tapPromise(options, fn);
}

Choose a reason for hiding this comment

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

high

The new tap, tapAsync, and tapPromise methods on QueriedHookMap are implemented inconsistently with the class's design.

QueriedHookMap is designed as a "view" over a HookMap for a specific stageRange. Its get(key) and for(key) methods correctly return a QueriedHook that is constrained by this stageRange.

However, the new tap methods delegate directly to the underlying this.hookMap:

return this.hookMap.for(key).tap(options, fn);

This bypasses the stageRange logic entirely, breaking the abstraction of QueriedHookMap. A developer using a QueriedHookMap instance would not expect tap() to ignore the query context.

The PR description focuses on adding these methods to HookMap for webpack compatibility. It's unclear if they are also needed on QueriedHookMap.

Given that QueriedHook (returned by for(key)) does not have tap methods, and adding them would be complex, I recommend removing tap, tapAsync, and tapPromise from QueriedHookMap to avoid this design inconsistency. If these methods are strictly required, their interaction with stageRange needs to be clarified and implemented correctly.

@martinjlowm martinjlowm changed the title Fix rspack plugin error with Yarn PnP paths Fix rspack plugin error for pino-webpack-plugin Jan 18, 2026
Remove tap(), tapAsync(), tapPromise() from QueriedHookMap as they
bypass the stageRange constraint by delegating directly to the
underlying hookMap. This breaks the abstraction since QueriedHook
doesn't have tap methods and the query context should be respected.

The HookMap convenience methods are kept as they correctly delegate
to for(key).tap() without any stage filtering concerns.
@martinjlowm martinjlowm changed the title Fix rspack plugin error for pino-webpack-plugin Add tap support for hookMap Jan 18, 2026
@chenjiahan chenjiahan requested a review from ahabhgk January 19, 2026 02:40
@ahabhgk
Copy link

ahabhgk commented Jan 19, 2026

These methods already deprecated by tapable, is there any plugin that still using these methods?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants