[Breaking Change][*] Chore: Use terser for optimizing cjs prod build

[etrepum]

Breaking Change

This may cause some regression in the cjs build size or cause some other configuration related issue, particularly for www. I suspect that most people in OSS are using esm builds at this point, but some extra scrutiny should be used at Meta when evaluating this PR.

Description

The cjs prod build has used @ampproject/rollup-plugin-closure-compiler for some time, but that project is abandoned (last release Aug 2021) and causes hard to debug issues whenever you end up using syntax that is valid JS according to the rest of the toolchain but not supported by that abandoned project (e.g. property initializers in classes).

terser is already used for the lexical esm build which has been in production for some time now, it is currently the most popular tool for this purpose, and it is maintained on top of a current toolchain.

To investigate the difference between the two I audited our size-limit action since I knew there was an outstanding issue related to it (#6852). Turns out that issue is correct and the size-limit action hasn't done anything useful since we moved it to a pull_request_target trigger. Our size-limit action also only measured dev builds which is fast but not useful, so I changed it to prod. Unfortunately for (good) security reasons you can't really test these in a PR since the workflow code is guaranteed to come from main, so I had a few commits here testing the action with the pull_request trigger. We might still want to consider having a more abstract method for measuring size, e.g. publishing an artifact that a safer workflow trigger can measure.

Closes #6852

Test plan

Before

Get an acorn stack trace in prod builds that only includes the line number in some build artifact and not any real indication of where the error is (fortunately you can attach a debugger locally, but it's a pain) whenever modern JS syntax is used. Most recently I ran into this working on #7046 but this isn't the first time.

After

Syntax support is consistent across all builds, dev and prod.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
lexical	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 14, 2025 5:21am
lexical-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 14, 2025 5:21am

[etrepum]

npm run size from this branch

  lexical - cjs
  Size:         29.69 kB with all dependencies, minified and brotlied
  Loading time: 580 ms   on slow 3G
  
  lexical - esm
  Size:         29.53 kB with all dependencies, minified and brotlied
  Loading time: 577 ms   on slow 3G
  
  @lexical/rich-text - cjs
  Size:         38.88 kB with all dependencies, minified and brotlied
  Loading time: 760 ms   on slow 3G
  
  @lexical/rich-text - esm
  Size:         31.71 kB with all dependencies, minified and brotlied
  Loading time: 620 ms   on slow 3G
  
  @lexical/plain-text - cjs
  Size:         37.38 kB with all dependencies, minified and brotlied
  Loading time: 731 ms   on slow 3G
  
  @lexical/plain-text - esm
  Size:         28.81 kB with all dependencies, minified and brotlied
  Loading time: 563 ms   on slow 3G
  
  @lexical/react - cjs
  Size:         40.8 kB with all dependencies, minified and brotlied
  Loading time: 797 ms  on slow 3G
  
  @lexical/react - esm
  Size:         32.98 kB with all dependencies, minified and brotlied
  Loading time: 645 ms   on slow 3G

npm run size from main

  lexical - cjs
  Size:         29.07 kB with all dependencies, minified and brotlied
  Loading time: 568 ms   on slow 3G
  
  lexical - esm
  Size:         29.53 kB with all dependencies, minified and brotlied
  Loading time: 577 ms   on slow 3G
  
  @lexical/rich-text - cjs
  Size:         38.3 kB with all dependencies, minified and brotlied
  Loading time: 749 ms  on slow 3G
  
  @lexical/rich-text - esm
  Size:         31.71 kB with all dependencies, minified and brotlied
  Loading time: 620 ms   on slow 3G
  
  @lexical/plain-text - cjs
  Size:         36.81 kB with all dependencies, minified and brotlied
  Loading time: 719 ms   on slow 3G
  
  @lexical/plain-text - esm
  Size:         28.81 kB with all dependencies, minified and brotlied
  Loading time: 563 ms   on slow 3G
  
  @lexical/react - cjs
  Size:         40.06 kB with all dependencies, minified and brotlied
  Loading time: 783 ms   on slow 3G
  
  @lexical/react - esm
  Size:         32.98 kB with all dependencies, minified and brotlied
  Loading time: 645 ms   on slow 3G

[etrepum]

All of the measurement differences are <1kb, e.g. lexical cjs prod went from 29.07 kB in main to 29.69 kB with terser (+ ~2.1%).

[potatowagon]

Run npm run build-www job looks fine

This may cause some regression in the cjs build size or cause some other configuration related issue, particularly for www

would the only risk be wrongly reported build size?

[potatowagon]

thanks for this upgrade!

[etrepum]

Run npm run build-www job looks fine

This may cause some regression in the cjs build size or cause some other configuration related issue, particularly for www

would the only risk be wrongly reported build size?

That’s the only known risk, I can’t know what else is going on in the www toolchain outside of lexical that could cause issues but it is very unlikely.