[Feature Request] Add SWC as a transpiler

[matthew-dean]

Feature Use Case

It would be nice to be able to generate .d.ts files, and use swc for syntax transforms a la https://swc.rs/. SWC is about 10x faster than Babel.

Feature Proposal

Add swc to the list of transpiler options, and run syntax transforms through it, similar to https://www.npmjs.com/package/rollup-plugin-swc

[wessberg]

Hey there.
Yeah, even though I've had more than a few issues with swc, I've thought about it too. It would make a lot of sense to add it here.

The thing that is holding me back is that given rollup-plugin-ts is already depending hard on babel, it might be a step too far for many users to also depend hard on swc, which does provide pre-built binaries for most environments, but not all (and also require @swc/core-linux-musl on Alpine Linux, so I'd have to figure out how to conditionally depend on that one).

What I really want to do is to declare babel and swc as optional dependencies in a way that works across package managers, as was also discussed in this PR.

I guess this would have to require an update to the major SemVer version in that it will require package consumers to add the babel dependencies to their own package.json files, which may start breaking on CI.

I'll mark this as a feature request, but it is in line with what I've wanted to do here anyway for quite some time.

[wessberg]

Hey there.

This has been implemented as part of v2.0.0!

[matthew-dean]

@wessberg

Thanks! I'm trying out 2.0.4 right now, and I'm running into this error:

1% (1): src/index.tsthread '<unnamed>' panicked at 'failed to parse `TP` as a version: invalid digit found in string', crates/swc_ecma_preset_env/src/version.rs:20:43
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[!] (plugin Typescript) Error: failed to handle: failed to parse `TP` as a version: invalid digit found in string
src/index.ts

I'm defining a swcConfig like this at the top of my file:

const swcConfig = {
  jsc: {
    parser: {
      syntax: 'typescript',
      tsx: true
    },
    target: 'es2018'
  }
}

And then doing this in my plugins:

isProd
        ? ts({
          transpiler: 'swc',
          swcConfig,
          hook: {
            // Always rename declaration files to index.d.ts to avoid emitting two declaration files with identical contents
            outputPath: (path, kind) => kind === 'declaration' ? './index.d.ts' : path
          }
        })
        : swc(swcConfig)

Note that when I run a "dev" build, it runs Rollup through the rollup-plugin-swc package, which works. We need a .d.ts file, so I was previously running rollup-plugin-ts without SWC, which also works, but is, of course, much slower. Any ideas?

[wessberg]

First, the target you provide in your swc config is not actually respected. If rollup-plugin-ts can resolve a browserslist, that will be used and passed on to swc. Otherwise, the target from your tsconfig will be used and a browserslist will be generated based on that. I realize this is a bit magical and in the case of swc I might consider changing this, but by design, use either a browserslist or the target in your tsconfig to decide which environments to support. The thing is, when you combine TypeScript with swc, you both have a target in your tsconfig and in your swc config. How do you decide which one to use? I've decided that TypeScript is always the "truth" to make it easy to understand and configure.

The stack trace from swc looks very much like an internal error related to swc's env feature not understanding that the version number for Safari Technical Preview is "TP", and it seems to expect to be able to parse it as a sequence of digits. The reason why this doesn't happen with rollup-plugin-swc is that it just uses the target: "es2018" from your swx config whereas rollup-plugin-ts always generate and pass a browserslist to swc's env feature: https://swc.rs/docs/configuration/supported-browsers.

Swc still does have a lot of of bugs like this. I'll work around it by not generating a browserslist based on the target ecma version if no browserslist was found and swc is used. I'll track it in a separate issue: #163

[matthew-dean]

@wessberg Thanks for looking into it!