feat(next-swc): introduce experimental tracing support for swc

[kwonoj]

Context: #34687 (comment)

It is a bit tricky to understand underlying performance characteristics inside swc when build steps involving swc's internals. Technically it should be possible to use a profiler with some custom swc build, but it is not easy job to set it up.

SWC recently introduced trace features for those reasons (swc-project/swc#3953), allow emitting Trace event format compatible (https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview) output. This PR ports over those features into next-swc under experimental config value to user to try out.

With this PR, trace will emit core swc's traces as well as one custom transformation in next-swc (emotion). Expect to expand trace over all existing custom transform passes eventually in further PRs.

To configure traces, next.config.js exposes this new experimental config value:

// next.config.js

{
...
  experimental: {
    swcTraceProfiling: true
  }
}

SWC will generate trace-${unixtimestamp}.json by default.

It is important to aware enabling trace all time is highly discouraged: observing code path is not free, and if build scales up trace will cost expensive time as well. User may want to use env variable, or other dynamic way to selectively enable trace instead.

Generated trace is compatible to trace event format, so existing visualizer can be used out of the box. Notably,

• catapult: chrome://tracing
• perfetto: https://ui.perfetto.dev/
• speedscope: https://www.speedscope.app/

And possibly other flamegraph visualizer as well. Technically it is possible to make output to work with chrome devtools' profiler, but that's not supported now.

This is example trace screenshot from bench/nested-deps.

As config already implies, this is experimental due to 1. config / internal swc impl might change, 2. there are missing traces for custom passes in next-swc.

Bug

• Related issues linked using fixes #number
• Integration tests added
• Errors have helpful link attached, see contributing.md

Feature

• Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
• Related issues linked using fixes #number
• Integration tests added
• Documentation added
• Telemetry added. In case of a feature if it's used or not.
• Errors have helpful link attached, see contributing.md

Documentation / Examples

• Make sure the linting passes by running yarn lint

[Brooooooklyn]

Great work!

[padmaia]

Should we output the trace to the .next folder where the other trace goes? I think that file is just named trace so maybe swc-trace? Also, I think an environment variable would make sense once it's not experimental, but I would defer to @timneutkens for API decisions.

[kwonoj]

Should we output the trace to the .next folder where the other trace goes? I think that file is just named trace so maybe swc-trace

I do not have strong preferences for this - this is mostly modeling after others like node --perf-basic-prof which leaves v8 traces to current cwd. Totaly can change if we prefer to move it to elsewhere.

[kwonoj]

Updated PR bit

• rename swcTrace config to swcTraceProfiling, to avoid confusion between next/trace slightly
• put trace to ./.next by default if filename not specified. Also, creates a path to dir if not exists.