Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What should we do about our closure compiler dependency? #23358

Open
sbc100 opened this issue Jan 9, 2025 · 0 comments
Open

What should we do about our closure compiler dependency? #23358

sbc100 opened this issue Jan 9, 2025 · 0 comments

Comments

@sbc100
Copy link
Collaborator

sbc100 commented Jan 9, 2025

Currently emscripten depends pretty strongly on closure compiler to get its absolute smallest output.

Over the years this is caused a lot of issue for us. For example:

  1. Bugs in closure compiler itself.
  2. Difficulty running closure compiler: Closure compile is available in 3 forms: JavaScript, Java, and native-compiled-gradle. All 3 of these have presented issues for us
  3. Opaque limitations of closure. For example, I recently discoverted that it minifies things differently inside a nest scope that it does at the top level. This basically blocked my recent change: Move modularization code into js compiler #23261
  4. Impossible to suppress warnings
  5. Jumping through crazy hoops to avoid minification:

    emscripten/src/shell.js

    Lines 28 to 29 in 0585506

    // if (!Module)` is crucial for Closure Compiler here as it will otherwise replace every `Module` occurrence with a string
    if (!Module) /** @suppress{checkTypes}*/Module = {"__EMSCRIPTEN_PRIVATE_MODULE_EXPORT_NAME_SUBSTITUTION__":1};
  6. Jumping through even crazier hoops work around limitations:
    // `eval`, Terser and Closure don't support module syntax; to allow it,
    // we need to temporarily replace `import.meta` and `await import` usages
    // with placeholders during preprocess phase, and back after all the other ops.
    // See also: `phase_final_emitting` in emcc.py.
    text = text
    .replace(/\bimport\.meta\b/g, 'EMSCRIPTEN$IMPORT$META')
    .replace(/\bawait import\b/g, 'EMSCRIPTEN$AWAIT$IMPORT');
    }

Finally, the future of closure compiler seems somewhat tenous and the npm packages have not been updated in 10 months.

We have a pretty annoying issue that there is not macOS arm64 binary still in npm: google/closure-compiler-npm#291. This means almost all mac users see warning messages and fall back to java version.

Can we remove our dependency on closure somehow?

@sbc100 sbc100 changed the title What should we do about our closure compiler dependency What should we do about our closure compiler dependency? Jan 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant