Questions on SWC and its infrastructure role

[narukeu]

I think SWC is no longer just a simple compiler; it has taken on the responsibility of being a major infrastructure component within the Rust frontend ecosystem.

Babel is not merely a "tool that transforms code from A to B"; it is de facto ecosystem infrastructure. It provides a default AST shape that everyone agrees on, along with a comprehensive suite of plugins, analysis tools, and transformation capabilities surrounding that AST. Many frontend tools directly utilize Babel's parser, traverse, and AST structures.

On the Rust side, my observation is that SWC is, in a sense, already playing a similar role:

1. It offers multiple sub-crates for parsing, traversing/visiting, and transforms.
2. Many frontend-related tools written in Rust directly depend on SWC's AST or related crates for parsing, analysis, and transformation.

Judging by crate usage, SWC has become more than just "a compiler that can replace Babel"—it is a core piece of infrastructure for Rust frontend tooling.

However, in terms of public presentation, the current focus still seems to be primarily on:

1. High-performance JS(X)/TS(X) compilation;
2. Integration with existing build tools (Next.js, Webpack, Rspack, etc.).

For the average frontend developer, this positioning is clear enough. But for those building frontend tools in Rust, the actual usage scenarios have clearly surpassed the baseline of just being a "Speedy Web Compiler."

Therefore, I have a few specific questions and thoughts:

Does SWC have the intention—or is it already in the roadmap—to view itself as "infrastructure for the Rust frontend ecosystem" and a "candidate for the de facto AST standard"? In other words, rather than just being a "Web development tool/compiler in Rust," is there a formal goal to explicitly "provide general-purpose infrastructure for other Rust frontend tools"?

Another observation is that in recent years, some open-source projects using Rust/Go have attempted to build "all-in-one" unified toolchains, implementing a parser, transformer, linter, formatter, test runner, etc., all within a single project. My personal view is that it isn't necessary to bind every link in the chain to the same project. A more reasonable model for the entire ecosystem might be: having a layer of relatively stable, general-purpose infrastructure (e.g., AST, parser), upon which other tools can implement their specific responsibilities (such as linters, formatters, bundlers, analysis tools, etc.).

From this perspective, SWC's position in the Rust frontend tool ecosystem is actually very critical: it has naturally grown into that "infrastructure layer." If the project is willing to embrace this positioning more explicitly—for instance by:

1. Stating the role of "Rust frontend infrastructure" more directly on the official website or README;
2. Introducing in the documentation how to leverage SWC's fundamental capabilities to develop other Rust frontend tools;

...then it would provide much greater reference value for other Rust frontend tools and help reduce the situation where every project reinvents its own AST/parser "wheels".

[kdy1]

Yeap. It was one of the goals of the project from the start, but

every project reinvents its own AST/parser "wheels".

this is not because of the documentation of SWC

[narukeu]

Yeap. It was one of the goals of the project from the start, but

every project reinvents its own AST/parser "wheels".

this is not because of the documentation of SWC

Thanks for the reply. My previous phrasing might have been ambiguous, and I apologize for the misunderstanding.

I wasn't trying to say that "SWC's documentation is the reason people are reinventing AST/Parser wheels."

What I really meant is:
Since SWC has aimed to be "infrastructure for the Rust frontend ecosystem" from the start, and its actual adoption in the ecosystem is indeed trending that way, perhaps the README or documentation could more explicitly inform other tool authors:

SWC is not just a high-speed compiler; it is also intended to be reused as a foundational layer for general-purpose Parsing, ASTs, and Traversal.

From a tool author's perspective, if this positioning were stated more directly in the README and official docs, it would be easier to intuitively feel that "I should depend directly on SWC, rather than building an AST/Parser from scratch."

So, my point is: if this "infrastructure positioning" were made more prominent in the official documentation—or to put it vividly, if "SWC invited these authors to use our library"—it might reduce the reinvention of wheels in the long run.