Typescript

[Ryan Brown]

We're currently using tsickle to convert typescript code to Closure Library goog.modules so we can compile it with Closure Compiler.

Are there plans for how to handle typescript with Closure Compiler now that Closure Library is sunset?

[Jan Kühle]

Hi there.

If the question is about Closure Library, see https://github.com/google/closure-library/issues/1214 and look for the headline "What about Closure Compiler?". In short, we will keep maintaining the relevant parts like goog.module or goog.require.

If the question is about tsickle, that still maintained. Though see https://github.com/angular/tsickle/#warning-unsupported. We believe Closure Compiler is hard use for TypeScript code unless everything you depend on is built for Closure Compiler. Long term the way forward is likely to use a bundler/minifiers like esbuild/swc/terser, which work much better with all the different packages available on npm.

-- Jan

[Ryan Brown]

On Thu, Jan 18, 2024 at 7:34 AM 'Jan Kühle' via Closure Compiler Discuss <closure-comp...@googlegroups.com> wrote:

Hi there.

If the question is about Closure Library, see https://github.com/google/closure-library/issues/1214 and look for the headline "What about Closure Compiler?". In short, we will keep maintaining the relevant parts like goog.module or goog.require.

Oh, ok. I guess I assumed that "We are committed to retaining the core functionality in Closure Compiler, while dropping its dependency on Closure Library" meant that Closure dependency management, reflection, defines, etc would get some new replacement that doesn't use 'goog'. But you're saying those will just continue to be maintained? Is there some new place we should get those function definitions from, or do we still need to load those from the last released version of closure library?

 

If the question is about tsickle, that still maintained. Though see https://github.com/angular/tsickle/#warning-unsupported. We believe Closure Compiler is hard use for TypeScript code unless everything you depend on is built for Closure Compiler. Long term the way forward is likely to use a bundler/minifiers like esbuild/swc/terser, which work much better with all the different packages available on npm.

-- Jan

On Thursday, January 18, 2024 at 11:57:43 AM UTC+1 ry...@derivita.com wrote:

We're currently using tsickle to convert typescript code to Closure Library goog.modules so we can compile it with Closure Compiler.

Are there plans for how to handle typescript with Closure Compiler now that Closure Library is sunset?

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/5d075515-e908-4590-bfdb-df7e0b2fd1f2n%40googlegroups.com.

[s...@google.com]

On Thursday, January 18, 2024 at 10:16:57 AM UTC-5 ry...@derivita.com wrote:

On Thu, Jan 18, 2024 at 7:34 AM 'Jan Kühle' via Closure Compiler Discuss <closure-comp...@googlegroups.com> wrote:

Hi there.

If the question is about Closure Library, see https://github.com/google/closure-library/issues/1214 and look for the headline "What about Closure Compiler?". In short, we will keep maintaining the relevant parts like goog.module or goog.require.

Oh, ok. I guess I assumed that "We are committed to retaining the core functionality in Closure Compiler, while dropping its dependency on Closure Library" meant that Closure dependency management, reflection, defines, etc would get some new replacement that doesn't use 'goog'. But you're saying those will just continue to be maintained? Is there some new place we should get those function definitions from, or do we still need to load those from the last released version of closure library?

The short answer is that we haven't fully fleshed out what this will look like quite yet.  One possibility is that we bundle a significantly pared-down goog.js file with Closure Compiler, which only includes the "primitive" functions that the compiler has special handling for.  The text was meant to indicate that this use case was not being forgotten, without promising any particular solution.