fix: Handle multiple calls to useExtracted & getExtracted

[amannn]

Refactor SWC plugin to correctly handle multiple useExtracted and getExtracted calls in a single file.

Previously, the plugin only processed the first useExtracted or getExtracted import it encountered due to storing hook information as single values and using break statements. This led to a bug where subsequent calls to these hooks in the same file were not transformed. The fix changes the internal storage from single Option values to a FxHashMap to track all relevant hook imports and updates the visitor logic to utilize this map for transformations.

---

 

---

Note

Track all hook imports via a map and transform every occurrence; add fixtures verifying multiple client/server hooks and update a sourcemap.

• SWC Plugin (packages/swc-plugin-extractor/src/lib.rs):
  • Replace single hook tracking with hook_local_names: FxHashMap<Id, HookType> to support multiple imports/aliases.
  • Update import handling for next-intl and next-intl/server to record each local and rename to useTranslations/getTranslations (preserving spans/ctxt).
  • Update variable declarator logic to rewrite callees based on the map for both direct and awaited calls; propagate translator namespaces.
• Tests:
  • Add tests/fixture/multiple-hooks with input, transformed output, and sourcemap covering multiple client/server hooks and aliases.
  • Adjust tests/fixture/alias-hook/output.map mappings.

^{Written by Cursor Bugbot for commit 325fff7. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Agent can help with this pull request. Just @cursor in comments and I'll start working on changes in this branch.
_{Learn more about Cursor Agents}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
next-intl-docs	Ready	Preview	Comment	Dec 2, 2025 3:57pm
next-intl-example-app-router	Ready	Preview	Comment	Dec 2, 2025 3:57pm
next-intl-example-app-router-without-i18n-routing	Ready	Preview	Comment	Dec 2, 2025 3:57pm

[amannn]

@cursoragent Do you think changes in this PR noticeably affect perf? Local tests don't show a significant difference … Or would you suggest any optimizations?

[cursor]

Looking at the changes, the performance impact should be negligible for several reasons:

Analysis

Before vs After:

Aspect	Before	After
Storage	Option<HookType> + Option<Id>	FxHashMap<Id, HookType>
Lookup	== comparison	Hash map .get()
Import processing	Early break after first match	Processes all imports

Why the impact is minimal:

1. FxHashMap is extremely fast - It uses the FxHash algorithm which is specifically optimized for small keys like Id. For 1-4 entries (typical hook count per file), the overhead is essentially zero.

2. O(1) amortized lookups - Both the old comparison and hash map lookup are constant time. The hash map has slightly more overhead, but we're talking nanoseconds.

3. Import processing is minimal - Removing the break means we now check all import specifiers, but files typically have only a handful of imports. The string comparison (orig_name == "useExtracted") is very cheap.

4. The real work is elsewhere - The expensive operations (AST traversal, message extraction, key generation with SHA-512) are unchanged.

Verdict

No optimizations needed. The fix prioritizes correctness and the code is already efficient. Your local tests confirming no significant difference is expected - the change is architecturally cleaner while maintaining the same performance profile.

If you wanted to micro-optimize (not recommended as it adds complexity for marginal gain), you could use a SmallVec<[(Id, HookType); 2]> for inline storage of typical 1-2 hooks, but FxHashMap is already the standard choice for this pattern in SWC's codebase.

---

 

_{Learn more about Cursor Agents}