[Feature Request]: Support for System JS as output format

[jonbjk]

What problem does this feature solve?

SystemJs is used in quite a few microfrontend architectures. Typically these use Rollup with output format "system", as build tool.
Are there any plans to support SystemJs output in Rolldown?

What does the proposed API look like?

import { defineConfig } from 'rolldown';

export default defineConfig({
  input: 'src/dummy.js',
  output: {
    dir: 'dist',
    entryFileNames: `[hash].system.js`,
    format: 'system',
  },
});

Results in:
ERROR unimplemented: output.format: system

[hyfdev]

Some notes:

• So far we don't have plan on supporting systemjs
• As a workaround, you could target to esm format and transpile the output to systemjs using other tools.
• We might provide a official/third-party plugin that does the above thing automatically

[izaakschroeder]

+1 from me. systemjs allows lower level access to module system plumbing than… say… import maps + ESM alone. As @hyf0 mentioned this is a pretty common thing for module federation which often needs to make low-level manipulation to the module resolution process. Also nice on the off chance you have to support ancient browsers that don't support ESM 😄

[7086cmd]

My ideas:

TL;DR SystemJS can be excluded from a separate .rs file, but the format requires specific actions and normalization. Using an internal plugin with the VisitMut trait can handle the format automatically.

1. SystemJS can be excluded from a separate .rs file. However, we should support the system format in the enum, as the manifest plugin requires specific actions to handle the SystemJS format. The format also introduces some keywords that require normalization, while normalizing the name in oxc via traverse is somewhat inconvenient at present.
2. We can utilize an internal plugin and implement the VisitMut trait to handle this. When the format is set to system, we can automatically enable the built-in plugin.
3. It appears that @vitejs/plugin-legacy requires the system format for legacy builds when polyfills are not included (related: https://github.com/vitejs/vite/blob/main/packages/plugin-legacy/src/index.ts#L437). Additionally, Using Rolldown with Vite v6 vitejs/rolldown-vite#43 mentions that the test for legacy requires the system format.
4. Rollup’s implementation of SystemJS is complex, which implies that implementing the system format internally would be somewhat burdensome. Using the oxc ast traverse is a more suitable approach, in my opinion.
5. I am uncertain whether oxc-transformer will support the system format in the future. However, the transformer may should pass all of Babel tests. Both sides can share the current status on this functionality.

[xavivars]

@hyf0 which type of feedback are you expecting to get?

[hyfdev]

@xavivars Basically it's about why you need systemjs format. However, the current conclusion is rolldown itself won't support systemjs in a very long time.

So for anyone who wants systemjs output, I suggest exploring the way of

• As a workaround, you could target to esm format and transpile the output to systemjs using other tools.

I'll have this issue on our next team meeting and see if we had bandwidth to push it forward.

• We might provide a official/third-party plugin that does the above thing automatically

[xavivars]

Basically it's about why you need systemjs format

We need it (currently) because some browsers we need to support don't work with ESM import maps yet. And same for NodeJS.

We're currently using rollup (which natively supports systemjs), and are hoping to migrate to rolldown to get the build-time benefits it brings

[hi-ogawa]

I just tested a simple idea of transforming each esm chunk into systemjs format via renderChunk hook. Here is my code
https://github.com/hi-ogawa/reproductions/tree/main/rolldown-systemjs (stackblitz)

export default defineConfig({
  input: ["./src/entry.js"],
  output: {
    dir: "dist",
    format: "esm",
    sourcemap: true,
  },
  plugins: [
    {
      name: "transform-chunk-systemjs",
      async renderChunk(code, _chunk) {
        const result = await babel.transformAsync(code, {
          babelrc: false,
          configFile: false,
          sourceMaps: true,
          plugins: [babelDynamicImport, babelSystemjs],
        });
        return { code: result.code, map: result.map };
      },
    },
  ],
});

It looks working for simple cases, but I'm not sure whether this approach works robustly on real projects. I'll test it later on rolldown vite legacy plugin use cases.