`TRANSPILE_ONLY` mode

[brad4d]

Summary

Add a TRANSPILE_ONLY mode that does the following:

• Error checking as usual
• Code changes necessary to generate running code, including:
  • handling goog.define()
  • handling goog.module()
  • transpiling down to the requested --language_out level, including the addition of polyfills
• Otherwise leave the code unchanged. No optimizations. No renaming.

Background

WHITESPACE_ONLY mode is borderline useless, because what it means is very badly defined. In many cases it results in output code that will not run. Several examples can be seen in this issue search.

https://github.com/google/closure-compiler/issues?q=is%3Aissue%20state%3Aopen%20WHITESPACE_ONLY

On the other hand SIMPLE_OPTIMIZATIONS does much more than developers often want when they're "just" trying to get an executable version of their project as fast as possible for testing and debugging.

[brad4d]

Rahul's agreed to look into how hard this will be to accomplish as part of investigating a related polyfill problem.

[niloc132]

Might be a typo, or I'm reading docs from the wrong place, but what is goog.declare()? In the context of goog.module I would assume it might have been meant to be goog.define() or goog.provide() (or if the context was goog.module.get, maybe goog.require() or goog.forwardDeclare()?) Or, possibly goog.declareModuleId() (or less likely, goog.module.declareLegacyNamespace())?

Aside, would it be possible to get an equivalent of https://google.github.io/closure-library/api/goog.html for this repo, and possibly forward the old page to this (or at least put up a note that it is archived/deprecated)? I'm looking at https://github.com/google/closure-compiler/blob/master/lib/base.js as the "modern" version of that file.

---

Would it be fair to say that TRANSPILE_ONLY is in some ways a "lighter" version of BUNDLE, and in other ways a "heavier" version of BUNDLE? That is:

• BUNDLE will chase goog.require() and goog.module.get(), loading other files recursively as needed, but TRANSPILE_ONLY will not (as neither is in your bullet list. Do users then need to include a complete list of JS files desired to be baked in when calling this, in the correct order?
• TRANSPILE_ONLY will fully parse the JS files it is running, making it somewhat slower than BUNDLE (which will only apply the regex required to discover dependencies), so that it can find syntax that needs to be transpiled down and discover required polyfills.

[brad4d]

@niloc132 s/goog.declare/goog.define/

edit done

[hills]

Perhaps this is the appropriate place to mention that --define= could be considered, as it does nothing in WHITESPACE_ONLY and this seems unhelpful.

[brad4d]

That is a good point. I think what we would want from this compilation mode is roughly:

1. Make all changes necessary to make the output code functional. This includes handling --define, goog.module(), and transpiling and polyfill injection appropriate for --language_out=ES_20XX
2. Skip all optimizations, the only "optimizing" that happens is that comments and whitespace are not output from the code printer.

Given this, perhaps it would be easier to think of this and implement it by starting with SIMPLE mode and removing optimizations.

[brad4d]

FYI, the functionality actually implemented does not include removing whitespace and comments, despite my last comment here. We decided that the primary purpose of this operating mode was to generate working JS as quickly as possible without worrying about output code size, so we skipped that extra removal.

[sbc100]

Since there has now been a new release of the npm package for closure compiler I've been trying to update emscripten. I'm running into a code size regression where it looks like closure is generating slightly worse code in a couple of cases. Could someone take a look at this delta: emscripten-core/emscripten#24679 (comment) Is this expected? Are the two forms not equivalent? Any idea why closure might no longer be generating the shorter form? cheers, sam

…

On Fri, May 23, 2025 at 10:49 AM Bradford C. Smith ***@***.***> wrote: *brad4d* left a comment (google/closure-compiler#4231) <#4231 (comment)> FYI, the functionality actually implemented does *not* include removing whitespace and comments, despite my last comment here. We decided that the primary purpose of this operating mode was to generate working JS as quickly as possible without worrying about output code size, so we skipped that extra removal. — Reply to this email directly, view it on GitHub <#4231 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD55ZLCU2W7XZGTH37AWJ3275NQVAVCNFSM6AAAAAB22EWJRSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMBVGMZTCOBUGY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[brad4d]

@sbc100 , could you please file a new issue for this?
Comments on closed issues tend to go into the void,
but new issues will get picked up by our triage process.

If you do, it would be helpful if you could provide a minimal bit of code that demonstrates the problem, along with the command line you used to run the compiler in the 2 cases.