test(javascript): run what the minifier writes for swc's execution tests - #22355

Summary

The stdout suite now runs swc's execution tests as well as terser's. There are two sets. The first is the tests in exec.rs: swc's harness runs each input with node and requires the minified output to print the same. The second is the fixtures that carry an expected.stdout, leaving out swc's port of terser's own tests, which the suite already runs. Each test is minified by webpack under its own options and under the options webpack ships with (compress: { passes: 2 }, mangle: true), run in terser's sandbox, and has to print what its input prints.

Of the 502 exec tests, the sandbox runs 497 inputs; the other 5 throw or print nothing there. Of the 150 fixtures, 135 print their expected.stdout in the sandbox. Of the other 15, 13 read what only node gives them, such as process or a timer, and 2 are modules. A floor on each count keeps a reader that stopped matching from passing quietly.

24 outputs print something other than their input. Published terser's output prints the same thing in every one of them, so they are terser's own miscompiles, and webpack adds none. An output therefore fails only where the reference's output does not fail the same way. The suite takes about 30 s, up from 25 s.

The readers for swc's fixtures, exec.rs and mangle.rs, and the probe of which options terser reads, move unchanged from the js-minify suite into test/helpers/swcMinifierTests.js so both suites share them. The js-minify leg still passes all 232 tests. The js-minify-stdout CI leg now also checks out swc.

What kind of change does this PR introduce?

test

Did you add tests for your changes?

Yes, the corpus is the test. I broke the checks and each phase on purpose, then restored them:

• With the reference check turned off, both swc tests fail on the 24 outputs terser also gets wrong.
• Skipping every input fails both floors, at 0.
• In the scope phase, not marking eval's scopes fails 18 runs here, where terser's corpus fails 5 files.
• Skipping the unused phase's second pass fails 72 runs here, beside 40 files in terser's corpus.
• Not rebuilding scope before mangling in the minify phase fails 3 runs here, beside 94 files.
• Descending past a visitor that stopped the walk fails 1 run here, beside 1 file.
• Never hoisting fails nothing here, since the hoist phase only skips or hands the scope to terser's own. The byte-identical suite catches it in 17 files.
• Each earlier sabotage (print, parse, output, mangle) still fails the same terser files as before, and now both swc tests too.

Does this PR introduce a breaking change?

No. Only tests and CI change.

If relevant, what needs to be documented once your changes are merged or what have you already documented?

n/a

Use of AI
AI was used. I found the execution tests in swc's tree and reproduced how its harness runs them. It checked each of the 24 differing outputs against published terser, measured how many inputs terser's sandbox can run, and broke the new phases one by one to measure what each corpus catches. I reviewed the result.

Summary by CodeRabbit

• Tests
  • JavaScript minification tests now cover cases from both Terser and SWC, including checks of generated output and execution results.
  • Existing Terser test coverage remains in place, alongside eligible SWC fixtures and execution cases when the SWC corpus is available.