Rust extractor + faster native transform

[timofei-iatsenko]

No description provided.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.04%. Comparing base (27e38f2) to head (1636627).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #236      +/-   ##
==========================================
+ Coverage   94.96%   95.04%   +0.07%     
==========================================
  Files          10       10              
  Lines        2603     2542      -61     
==========================================
- Hits         2472     2416      -56     
+ Misses        131      126       -5     

Flag	Coverage Δ
unittests	95.04% <ø> (+0.07%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 9 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[andrii-bodnar]

Please update the repository url

[timofei-iatsenko]

Let's agree on the package/repostiry name first, then i will make this PR ready to be merged.

[andrii-bodnar]

Do we need all of these versions here?

[andrii-bodnar]

There is a lot of commented code in this workflow. Is there anything we can do to eliminate it?

[andrii-bodnar]

Some planning artifact

[timofei-iatsenko]

It's not planning artifact. It's an ADR, (architecture decision record), which is answering on a question why we decided to do this or not that, etc

It's not for AI, it's for further contributors

[andrii-bodnar]

Can we split the transformer out of this PR? The extractor and transform() are independent surfaces - extraction depends on lingui_extractor + lingui_macro, while transform() only needs lingui_macro plus the shared detect_parser_config. Nothing in the extraction path touches transform.rs.

Landing them separately would shrink this draft a lot, de-risk the first native publish, and let the transform's design settle on its own (the warnings-as-fatal handling, sourcemap dedup, etc.).

One architectural note: the extractor logic lives in a pure crates/lingui_extractor, but the transform logic sits inside the napi binding crate (packages/lingui-swc/src/transform.rs). I'd rather see it as a crates/lingui_transform too, so packages/lingui-swc (or rust-tools if we agree on this name) stays thin FFI glue and the split is uniform - crates = logic, package = bindings. That also makes the transform testable without napi.

So my suggestion: extractor in this PR, transformer as a follow-up. Keeps each PR focused and the boundaries clean.

[timofei-iatsenko]

I’d like to clarify my perspective on this PR to make sure we're on the same page.

It might look like I’m the one pushing hard to get this merged, but that’s not really the case. I don’t use this functionality in my current projects or pet projects. I created this contribution simply because I had the capacity and knew it would bring massive value to the project and community. Honestly, I believe the core project benefits from this much more than I do - it’s a solid, high-impact improvement.

Right now, the process feels overly bureaucratic and slows us down from iterating fast and delivering value. Instead of focusing on actual engineering work, I'm spending time on administrative overhead that isn't really necessary. For context, this exact code is already deployed and actively used by part of the community via the lingui-swc package, where it has been thoroughly proven to work.

Splitting this PR into smaller parts and delivering them separately would take a significant amount of extra time. Since both features will end up merged anyway, breaking them apart now means I’d have to waste hours fixing temporary test failures and type mismatches, only to recombine them later.

As a core contributor (though not an official maintainer), my available open-source time is limited, and I’d much rather spend it on meaningful engineering tasks.

If you strictly require this code to be split, refactored, and reformatted according to these administrative guidelines, I’m open to doing that as paid consulting work. Otherwise, I recommend merging this PR as-is so the main project can benefit from these improvements immediately without further delay.

[andrii-bodnar]

Thanks for laying out your perspective - let me be equally direct about mine, so we can reset this conversation and move to a productive place.

Asking to split an 8k+ line draft into reviewable pieces isn't administrative overhead - it's standard engineering practice, and it exists precisely because it makes delivery faster. Smaller, focused PRs get reviewed in hours instead of weeks, land independently, and are far easier to debug and revert. What actually slows a project down is a monolithic draft no one can responsibly review in one pass. I'd also note the timeline: my feedback was posted on June 18 and sat unanswered for over a month. The pace of this PR has not been constrained by review requirements.

Framing a routine change request as billable work is not a mode of collaboration that works here. Responding to review feedback is a normal part of contributing to any open-source project - for everyone. I appreciate that your open-source time is limited (so is ours), but review requests can't be met with an invoice.

That said, I understand the practical cost of splitting at this stage. Since both halves will land anyway, I'm fine with keeping the extractor and the transform in this PR.

So let's set the framing debate aside and focus on getting this from draft to merge-ready:

• Resolve the open design points and comments above.
• Mark it ready for review once that's done, and I commit to a fast review turnaround.

Going forward, though, let's treat splitting as the norm: work of this scale gets proposed and broken into reviewable PRs from the start. That's not process for its own sake - it's how we keep iteration fast for everyone.