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