#991761 ITP: swc -- A super-fast typescript / javascript compiler written in rust

Package:
wnpp
Source:
wnpp
Submitter:
Jérémy Lal
Date:
2026-08-21 00:17:02 UTC
Severity:
wishlist
Blocked By:
Bug Title
996644

  1

ITP: node-node-rs -- helper library for node-rs

wishlist stable testing unstable 9 months ago

996634

  3

ITP: node-napi-rs -- minimal library for Rust-based native NodeJS modules

wishlist stable testing unstable 3 months ago

#991761#5
Date:
2021-08-01 10:01:46 UTC
From:
To:
* Package name    : swc
  Version         : 1.2.70
  Upstream Author : kdy1 <kdy1997.dev@gmail.com>
* URL             : https://swc.rs/
* License         : Apache-2.0 or Expat
  Programming Lang: Rust, Nodejs
  Description     : A super-fast typescript / javascript compiler written in rust

swc is a typescript / javascript transpiler.
It consumes javascript or typescript file written in one version
of these languages and emits javascript code which can be executed
on javascript engines that are not yet supporting latest features.
.
It is an order a magnitude faster than similar projects written in
javascript.
.
It also provides spack, a full featured javascript modules bundler
that can do tree shaking among other things.

swc is a game changer for javascript development / deployment.
It can transpile, bundle, minify a large project in second(s).
It is now quite mature and usable.

#991761#10
Date:
2021-10-15 14:20:03 UTC
From:
To:
Hi Jérémy,

Quoting Jérémy Lal (2021-08-01 12:01:46)

What is status on this?

Would you be interested in my help on creating+maintaining this?


 - Jonas

#991761#15
Date:
2021-10-15 15:15:43 UTC
From:
To:
Le ven. 15 oct. 2021 à 16:20, Jonas Smedegaard <jonas@jones.dk> a écrit :

Nothing done.

Of course ! I created this ITP to lure someone into it :)
First thing is to make sure debian rustc version matches upstream
requirement...

Jérémy

#991761#24
Date:
2021-10-17 00:15:49 UTC
From:
To:
Quoting Jérémy Lal (2021-10-15 17:15:43)

Excellent.

As you might have noticed, I prepared some build-dependencies.

...and no, the issue with requiring nightly is not crucial: I have
patched it away in the preliminary packaging now living at
https://salsa.debian.org/js-team/node-swc-core


 - Jonas

#991761#29
Date:
2022-05-06 22:57:47 UTC
From:
To:
1.2.177 draft 1 needs embedding 197 crates (119 missing, 4 broken, 4
incomplete, 61 outdated, 8 ahead); builds in ~30 minutes with a 2-core
i5 CPU; not yet usable as it needs to link with node-napi-rs that is not
yet packaged.

My plan now is to keep up with upstream code development, package
dependencies (notably node-napi-rs), and encourage the Rust team to
update/upgrade existing but unaligned crate packages.

You can help by building this draft package and try improve integration
with draft packaging of node-napi-rs available at
<https://salsa.debian.org/js-team/node-napi-rs>, and provide feedback
here about that.

You can also help by joining the Rust team in Debian and help unbreak
and upgrade packaged crates, and add more:
https://salsa.debian.org/js-team/node-swc-core/-/blob/debian/latest/debian/TODO


Thanks,

 - Jonas

#991761#46
Date:
2026-05-09 22:14:08 UTC
From:
To:
Hi!

I'm working on updating node-rollup to v4 [1], which needs the SWC
ECMAScript crates (swc_ecma_ast, swc_ecma_parser, etc.).

Since 2002, the last message, rust-swc-core is already in the archive (63.1.1+ds) https://tracker.debian.org/pkg/rust-swc-core, but the swc_ecma_* crates are excluded from the orig tarball via Files-Excluded in debian/copyright. The newer swc_es_* are available but have an incompatible API that rollup hasn't adopted.

Would it be possible to un-exclude swc_ecma_* so we can package them?
That might help unblock the node-rollup v4 package. Please let me
know if I could explore that option or what is the current strategy, so to explore this without clashing with anybody.

[1] https://bugs.debian.org/1092721

Best,

Juan

#991761#51
Date:
2026-05-11 21:32:12 UTC
From:
To:
Hi Juan,

The plan is to...

 1. get src:rust-swc-core upgraded to newest upstream version
    and then keep up with that.
 2. include as many parts as possible with the Rust crates available,
    and package missing crates.
 3. when enough is included, package src:node-swc-core
    (this bug).
 4. when enough is included, have src:rust-swc-core provide swc binary
	(see bug#1099759)

Recently I reached 1), and earlier tonight I took a step towards 2),
also reorganizing patches to ease tracking of missing crates: At
https://salsa.debian.org/debian/rust-wasmtime/-/tree/debian/latest/debian/patches
you can see in the patches 2003_* the crates that are still missing.

Right now, the best you can do to help is package some of the missing
Rust crates.

Thanks,

 - Jonas
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmoCStYMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhXKkQAKe5fDiB8HkmOus6Xi/VKMUwPLWRS9GEcf1gUTzG
tWYpreMXreVVmCfm85wV4kZtwYgUKWOIU98lAhztQcj192k5R0bLnQjM97I/CUxP
DtZVnRFQklPyXbpMfYKiSah9jtjmZdkPv4CfnveAhL0NM0fWaWGuZs8gSh9QnrZP
363QH8zkmH8X4iA4avXDxGB1Wrlt0CrisJgorJJ5Ciu2bbml/prEYzvHG1Kv3jBd
/bnZxVuSpeBSDtjWYsyrxqD2hncr9OZu2+OhbVtj2PaiAltr4OuI0waOGpMv6pb+
U5ZEog6zouW4Gptztjb3wjxsEK3KifgtB2uzCBE8XFUHO6lIFSZmJYLHfc2dV0TO
ArrOQwDWY39C+k2KG0GUpnrETFErW9YTDtR05VtqDPYvTm5Dcpkh7NrZm+/5qlch
ZysVzt3eGvISld69tKLZz6zX9Ni948cyhNgnKq9OVW3/ioSF1yuD03lBUnDd4c2q
EdoWkRApBzKh6cLo6GBiAHL2WOOSrbJSCK50TOija/YFNnawan11NqLbqht5dtFe
SMmbkIRVtZy//+EQLyXQsBV7CYXw2YgYLx1ovyn5gyRvtnfJsxH9Q+E4ocLGuzij
u++44TKT082Bxt3Lttbodo/O5HSq+Rt7F/tuYWBsXptKWhu0b1aSnhaz7/9CtmxX
j8/q
=kGZh
-----END PGP SIGNATURE-----

#991761#56
Date:
2026-05-11 23:17:43 UTC
From:
To:
Hi Jonas,                                                                                                                            
Thanks for the update and the heads up 

I'd like to start by packaging some small missing crates from your 2003_* patches in rust-swc-core, while I catch up with the team practices.


I'm thinking of starting with radix_fmt,  and then dragonbox_ecma. They are also in my node-rollup v4 build, so packaging them helps both packages.

Are you already working on any of those? 
Happy to pick up others from the list too.                          

Thanks,                                                                                                                               
Juan             

#991761#61
Date:
2026-05-12 04:53:41 UTC
From:
To:
Quoting Juan (2026-05-12 01:17:43)

That sounds great.

I follow the normal praxis in Debian of announcing as ITP bugreports
the packages that I am working on to avoid duplicate work.

I recommend that you do the same, and that you check for existing works
e.g. at https://www.debian.org/devel/wnpp/prospective (which in my
experience is faster to load and search through than other interfaces)
instead of asking me directly: It slows us both down (a bit) to have a
conversation about something that is already public knowledge, and I
might not be the only one following this praxis. I am aware that the
policy in the Rust team contradicts what I am recommending here - I
have no interest in discussing pros and cons of Rust team policies,
just sharing my opinion to help you form your own.

Since you seem to be working from within the Rust team, another thing
that is helpful is to update/upgrade packages maintained in that team
which affects the swc packages. You can see the affected packages at
https://bugs.debian.org/src:rust-swc-core

Thanks a log for your help!

 - Jonas

#991761#66
Date:
2026-05-12 05:32:25 UTC
From:
To:
Quoting Jonas Smedegaard (2026-05-11 23:32:12)
Uhm, that bug reference for 4) and link to patches are both wrong: This
bugreport is tracking both Nodejs interface and CLI tool, and the link
to patches is
https://salsa.debian.org/debian/rust-swc-core/-/tree/debian/latest/debian/patches
as it seems from your followup email that you already have figured out.

Sorry for the confusion,

 - Jonas

#991761#71
Date:
2026-07-19 03:13:27 UTC
From:
To:
Hi Jonas,

All blocking dependencies for the ECMAScript crates are now in unstable:
dragonbox_ecma, chili, jsonc-parser, browserslist-rs, and radix_fmt.

I have prepared a branch with the patch changes needed to enable ecma crates:
https://salsa.debian.org/mendezr/rust-swc-core/-/tree/debian/enable-ecma-crates

Summary of changes:
- Drop 5 patches (2003_browserslist-rs, 2003_chili, 2003_dragonbox_ecma,
  2003_jsonc-parser, 2003_radix_fmt) -- deps all in sid now
- Rewrite 2003_lexical and 2003_napi for the new context
- Expand 2004_limit_crates from 5 to 23 workspace members
- Extend 2005_avoid_crate_testing for ecma crate test binaries
- Add packages_virtual entries in debian/rules

After this, rust-swc-core provides librust-swc-ecma-{ast,parser,codegen,
minifier,visit,utils}-dev plus swc_compiler_base -- everything node-rollup v4
needs for WASM parsing (#1092721).

All patches apply cleanly (dpkg-source -b . verified).

Juan

#991761#76
Date:
2026-07-21 00:05:33 UTC
From:
To:
Hi Jonas,

My 2026-07-19 note on #991761 wasn't Cc'd to you, so a quick follow-up: all
deps are now in the archive (radix_fmt cleared NEW), and I've prepared the
patches to enable the SWC ecma crates. Details and branch are in the bug:

https://bugs.debian.org/991761

This unblocks node-rollup v4 (#1092721). Glad to send them whichever way
suits you.

Cheers,
Juan

#991761#81
Date:
2026-07-21 00:40:01 UTC
From:
To:
Hi Juan,

Quoting Juan Manuel Méndez Rey (2026-07-21 02:05:33)

Oh - sorry, but I have in the meantime updated the pacakage, so your
patch no longer applies. Also, it turns out that swc_ecma_preset_env
needs precomputed-map which needs packaging. Can you do that?

What I would prefer is that instead of a single giant git commit with
all changes that you instead could prepare a set of git commits with
more narrow, "atomic" commits. It is fine that you share in your
private branch as you have done above, then I can cherry-pick from
there.

 - Jonas

#991761#86
Date:
2026-07-21 09:50:21 UTC
From:
To:
Hi Jonas,

Answering below


Now: ecma crates. Changed now to 3 atomic commits (as requested) on debian/enable-ecma-crates-v2 in my fork: https://salsa.debian.org/mendezr/rust-swc-core/-/commits/debian/enable-ecma-crates-v2

I took a look to the the icu_properties exclusion (to enable ecma_minifier/transforms) but it is a different matter in scope, so I think it is better to work on that on a different batch of work. The dev-dep chain cascades and rollup doesn't need those, my main objective to unblock rollup-v4

Please, have a look,
Juan

#991761#91
Date:
2026-07-21 21:44:12 UTC
From:
To:
Quoting Juan M. Méndez Rey (2026-07-21 11:50:21)

Great!

For future sake, please reference ITP bug number instead (and mention
source URI in the ITP). Not relevant here - the package has already
entered the archive (which leads to another note: please target
experimental initially, and unstable only when package can migrate to
testing).

Thanks for the more atomic patches. I have cherry-picked the first two,
as the third is unneeded (only needed for crates that gets exposed with
each of their features, which for this gigantic workspace I will do
only where really needed by reverse dependencies).

The package fails to build, however. I was assuming that you had tested
that - I am ok with untested patch proposals, but please in future
mention explicitly if you are proposing changes that you have not
tested.

Thanks,

 - Jonas

#991761#96
Date:
2026-07-22 06:38:07 UTC
From:
To:
Hi Jonas,

Sorry about the earlier email, it was sent before precomputed-map was merged and and uploaded thanks to another DD. But the important part is that I hadn't tested with sbuild.

Patches per commit

Targeting experimental in changelog, is this what you meant?
Branch pushed to: https://salsa.debian.org/mendezr/rust-swc-core/-/tree/debian/latest

Cheers,
Juan

#991761#101
Date:
2026-07-22 22:01:52 UTC
From:
To:
Quoting Juan M. Méndez Rey (2026-07-22 08:38:07)

No, what I meant was not about your proposed patches to the swc package
but about your newly introduced precomputed-map package:

When you initially introduce a new package to Debian, you must build
with binary packages includd, but such releae is not permitted to
transition to testing. It is problematic to have packages in unstable
that are not intended for migration to testing, and it is therefore a
recommended pattern to release such known-unmigratable package to
experimental, and then re-release to unstable (as a build without
binaries) when the package is accepted into Debian.

Thanks.

Please do not include changes to changelog in commits that changes
code - changelog it updated separately from codechanges, to make it
easier to later revert or cherry-pick across branches (e.g. reuse a
bugfix targeted unstable in a change to stable or oldstable).

your addition of patch 2008 seems a combination of multiple somewhat
independent things:

* changes arguably better suited as extensions to patch 2005
  * setting test = false seems too invasive - is that really necessary?
* tty-emitter feature workaround
* bugfix for missing ctxt field seemingly relevant to push upstream

Your git commit "add patch 2007_narrow_icu_exclude" seems better suited
as extension to patch 2003_icu_properties, and does multiple things
beyond adding that patch:

* edits changelog (please omit that)
* embedding crates
* exclusion and dropping embedding of other crates
* petgraph fix seemingly belonging to another patch

Your git commit "add patch 2006_avoid_autodiscovery" seems better
suited as extensions to patches 2003_*.

Ideally, patches should be possible to drop independently, or at least
collateral changes should be sensible to the patch itself, not be
"magically" triggered by changes in other patches.

 - Jonas

#991761#106
Date:
2026-07-23 14:45:56 UTC
From:
To:
Hi Jonas,

I restructured the patches following the feedback:

5980141 extend 2002_petgraph with GraphMap generic fix for petgraph 0.6.x
22ad75a consolidate 2004/2006/2007 into 2003 patch series
63ecbbc consolidate 2008 test gating into 2005_avoid_crate_testing
24697bd add 2005_parser_doctest_ignore for tty-emitter doctest
c2e910c add 2005_ecma_ast_ctxt_fix for missing ctxt field in test fixture
42a143d add Build-Depends for ecma crate builds
3e400e2 update changelog for ecma crate additions

Regarding test = false: the testing crate is workspace-internal
and not in Debian. Several crates have #[cfg(test)] code importing
it, so lib tests can't compile without it. This extends the pattern
already in your 2005 patch.

https://salsa.debian.org/mendezr/rust-swc-core/-/commits/debian/latest

Please, let me know your thoughts,

Best,
Juan

#991761#111
Date:
2026-08-21 00:15:27 UTC
From:
To:
Hi Jonas,

Posting on the bug for allowing everyone to be in sync.
Thanks for all your work so far nd moving this forward.

I was doing some status check today:

rollup 4.62.5 (released Aug 20) bumped its SWC pins to match 76.0.2
exactly: ecma_parser 44.0, ecma_ast 28.0, compiler_base 63.0.
radix_fmt is now in sid too, which was the last missing external dep.

Are you planning to enable ecma_parser/codegen/minifier/compiler_base?
Happy to prepare patches if useful.

Thanks,
Juan