Potential LoongArch support

[darkyzhou]

Hi SWC team,

I'm interested in adding LoongArch support to SWC. LoongArch is a new RISC architecture that's gaining traction in China's server and desktop market. I'm willing to contribute to the porting work and wondering if the team would be open to accepting such support?

Would appreciate any thoughts or technical guidance on this. Thanks.

[kdy1]

I want to support it if it

• is supported by rustc
• supports building from Github Action without using VM

[darkyzhou]

Thanks for your response. I understand your concern about maintenance costs. As a hobbyist, it's challenging to provide concrete usage data for SWC on LoongArch. However, since SWC is such a fundamental library in the frontend ecosystem - any frontend developer on LoongArch could encounter project installation failures due to incompatibility of SWC.

As a widely-used and valuable project, I believe SWC should strive to serve more users. To balance between the needs and maintenance costs, perhaps we could consider a tiered support model similar to what WasmTime uses? For platforms like LoongArch or BSD, we could introduce a "tier 3" or "community-maintained" status, where support is provided on a best-effort basis without strict guarantees or CI tests. This way, the SWC team wouldn't need to maintain these platforms directly - the maintenance would be handled by the community instead.

Following is part of the tier 3 description of WasmTime:

This baseline level of support notably does not require any degree of testing, fuzzing, or verification. As a result components classified as Tier 3 are generally not production-ready as they have not been battle-tested much.

Features classified as Tier 3 may be disabled in CI or removed from the repository as well. If a Tier 3 feature is preventing development of other features then the owner will be notified. If no response is heard from within a week then the feature will be disabled in CI. If no further response happens for a month then the feature may be removed from the repository.

If this sounds like a good approach, I'd be happy to help with documentation and other necessary work.

[kwonoj]

It's my personal take but I'm not sure if we can apply same practices like suggested. Swc's release cadence is very short, and usually it could be short than a week or even day doesn't sufficiently give buffer to notify / amend the failures.

[darkyzhou]

I think we can start with a simpler approach for now. For example, if the LoongArch build fails when releasing version 1.3.100, we can just accept the failure and notify the relevant maintainers. Their fixes would then be incorporated in the next release. This asynchronous support model can further reduce the burden on the SWC team.

I understand that missing a specific version might cause inconvenience for users, but I believe this is the essence of tier 3 support. Additionally, I think we can be reasonably confident because the majority of SWC's codebase seems to be cross-platform enough and build failures will be quite rare.

[kwonoj]

build failures will be quite rare.

I'm afraid this is not the case, given the experiences with freebsd support and we eventually dropped support for the freebsd for this exact reason.

I am feeling this thread is not a feasible way to explore path forward since discussion started including a multiple new concepts in a single approach. There are multiple questions need to be addressed

• should swc/core support new native arch now?
• what's the backing rational to support new native arch can be quantified?
• what prevents those arch user to use swc/wasm? Should we improve those instead if it's minor papercuts?
• should swc/core introduce new tiered native platform support?

I'd hesitant to say start for now approach as reverting back those decision would be a major effort. We took more than a year to drop freebsd support. I'm not trying to say yes/no in an immediate way, more of trying to get the right timeline and logistics to make core team managable. In my opinion, the questions need to be addressed and planned to move things forward. Would like to suggest to have a RFC and also trying to quantify usebase even if it's vague. For example, if other npm lib like rollup have new arch support - what's the active userbase? Are there meaningful increasement after having those support?

[darkyzhou]

Thank you for the detailed feedback. I understand the concerns and agree that we need a more structured approach.

• Regarding quantifying the userbase: I plan to first create and maintain a LoongArch fork of swc to gather concrete usage data and feedback. This will help us better understand the actual demand and potential impact.
• About the RFC: I acknowledge that a comprehensive RFC is needed. I'll need some time to prepare one that thoroughly addresses the details and maintenance implications, maybe based on real-world usage data from the fork.
• On using swc/wasm: While this could be an alternative solution, there are practical challenges. Many downstream dependencies directly rely on swc/core, and migrating them to use swc/wasm for LoongArch would require extensive changes across multiple packages, which seems impractical at this scale.