Potentially Breaking Change: Turning down in-browser transpilation

[Stephen Hicks]

If you don't use the debug loader, you can stop reading now.

TL;DR: The debug loader will stop down-leveling sources on July 25.

6 years ago we added a feature to the Closure Debug Loader that would detect when source files contained newer language syntax than was supported by the browser.  This was extremely useful at the time for transitioning to ES 2015, but was always intended as a last recourse "stop gap" when server-side transpilation was unavailable.  In the meantime, a number of better server-side solutions have cropped up and this feature is finally no longer needed.  We will be removing the in-browser transpiler on July 25.

This should only affect you (1) if you are using the debug loader, (2) are running with newer language features on older browsers that don't support them, and (3) only after you update to a new version of the library (NOTE: if you're pulling base.js directly from a raw.github-style URL, this will happen immediately - we highly discourage this practice).

If you are relying on the debug loader at all, we recommend looking into alternative bundling solutions.  There are a number of very performant bundlers available that should greatly improve your development experience (note also: the debug loader should never be used for production).  For Closure dependency management, consider closure-webpack-plugin if you need downleveling.  Moreover, modern browsers are keeping up with the EcmaScript spec a lot faster than they were in 2015, so in many cases downleveling is not even required anymore (and you can use a compiled binary to test against older browsers when necessary).

If anyone anticipates this change to cause undue hardship, please let me know and we can look into other options and whether it makes sense to extend the timeline.

You can also follow this discussion at #1170 on the GitHub issue tracker.

Thanks!

Steve Hicks, on behalf of the Closure Library team

========

FAQ:

How do I know if this will affect me?

If you write <script src="path/to/base.js">, <script src="path/to/my/deps.js">, and goog.require('my.namespace') in your HTML, then you are using the debug loader. This will still work, provided your sources do not use features that are newer than the browsers it runs on. Closure Library itself may use any Stage 4 features, which should generally be supported by all evergreen browsers, but may not be available in all older browsers. If you need to run uncompiled code on older browsers, consider using a bundler that does minimal downleveling.

[Ryan Brown]

Is there a recommendation for what we should be using instead of debug loader if we don't need downleveling?

We use typescript converted to goog.modules using tsickle.
We use the debug loader for development because it gives us fast builds and source maps work so we can debug things.

Closure Compiler has a BUNDLE mode, but it outputs broken source maps (e.g. it applies the sourcemap from the last typescript file to the entire bundle). We need to be able to debug our development code, so that's not an option.

We use esbuild for other things in our project, but it doesn't support goog.module

We don't use webpack and it seems like a lot of work to integrate it into our build process just for closure-webpack-plugin. Is there some reason it's better than the debug loader? Is the debug loader going to go away?

--

---
You received this message because you are subscribed to the Google Groups "Closure Library Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-library-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-library-discuss/a1bcfbed-6cd2-4031-81de-4287e91d9dacn%40googlegroups.com.

[Steve Hicks]

Short answer: the debug loader is not going away any time soon, but we'd like to get rid of it someday.

Longer answer: while Closure Compiler is a powerful optimizer, it does not provide the best experience for development.  If there's a bug in its sourcemap handling, that would definitely be worth reporting, but overall I'd recommend using vanilla tsc to convert your TypeScript to ES modules, which esbuild can support (at least for development).  To the extent you have any Closure JS, I would recommend migrating it to TypeScript.  Overall, the Closure dependency management system (specifically - goog.provide, goog.require, and goog.module), while revolutionary when it was first introduced, is now a bit of a dead end, and the best bet is to move away from it whenever possible.

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-library-discuss/CAMLmKmZXJJymuSw10O2OX09XHuLXt4mfz2oZ%3DWYod72RW8N9Hw%40mail.gmail.com.

--

*If you get an email from me outside of my normal 10-6 it is not because I'm always on or expect an immediate response from you; it is because of work flexibility.  Evening and weekend emails are a sign I allocated some regular working hours for other things (such as family, gym, friends,...).  And I encourage you to feel free to do the same.

[Ryan Brown]

On Tue, Jul 19, 2022 at 7:20 PM 'Steve Hicks' via Closure Library Discuss <closure-lib...@googlegroups.com> wrote:

Short answer: the debug loader is not going away any time soon, but we'd like to get rid of it someday.

Longer answer: while Closure Compiler is a powerful optimizer, it does not provide the best experience for development.  If there's a bug in its sourcemap handling, that would definitely be worth reporting, but overall I'd recommend using vanilla tsc to convert your TypeScript to ES modules, which esbuild can support (at least for development).  To the extent you have any Closure JS, I would recommend migrating it to TypeScript.  Overall, the Closure dependency management system (specifically - goog.provide, goog.require, and goog.module), while revolutionary when it was first introduced, is now a bit of a dead end, and the best bet is to move away from it whenever possible.

That sounds like good advice in general. 

I guess I forgot to mention that our typescript depends on the Closure Library.

So we still need something to handle things like `import Field from 'goog:goog.editor.Field';` 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-library-discuss/CAABDHWaJeTYnHAdB4Ycey0zcAEvXRZsku2%3D-hFCpva%2Bwp5sw_w%40mail.gmail.com.

[Steve Hicks]

On Wed, Jul 20, 2022 at 1:15 AM Ryan Brown <ry...@derivita.com> wrote:

On Tue, Jul 19, 2022 at 7:20 PM 'Steve Hicks' via Closure Library Discuss <closure-lib...@googlegroups.com> wrote:

Short answer: the debug loader is not going away any time soon, but we'd like to get rid of it someday.

Longer answer: while Closure Compiler is a powerful optimizer, it does not provide the best experience for development.  If there's a bug in its sourcemap handling, that would definitely be worth reporting, but overall I'd recommend using vanilla tsc to convert your TypeScript to ES modules, which esbuild can support (at least for development).  To the extent you have any Closure JS, I would recommend migrating it to TypeScript.  Overall, the Closure dependency management system (specifically - goog.provide, goog.require, and goog.module), while revolutionary when it was first introduced, is now a bit of a dead end, and the best bet is to move away from it whenever possible.

That sounds like good advice in general. 

I guess I forgot to mention that our typescript depends on the Closure Library.

So we still need something to handle things like `import Field from 'goog:goog.editor.Field';` 

If you're using Closure Library from TypeScript, I assume you're getting typings from somewhere (I'm aware of a couple external projects that provide .d.ts versions of the library).  I wonder what it would take to transform these libraries into something more standard (i.e. CommonJS, ESM, etc).  It's not something we'd be looking to do (there's a handful of particularly sticky goog.provide files that we're stuck with due to thousands of usages in our codebase, but if you're not cleaning up the world, it should be quite a bit more tractable), but it could bridge some gaps and allow better interop with esbuild and others.  And an approach that sat on top of the library with a repeatable transformation would have the benefit of tracking any upstream changes we push pretty trivially (IIUC that's how the .d.ts versions already work).

In a different direction, I wonder if you could take inspiration from the webpack plugin to make something that would work directly with esbuild?

Anyway, this isn't an urgent issue - it'll be at least a year or two before we're even close to thinking about doing anything with the debug loader, and there's also a possibility of just spinning it out of base.js so that it's a separate opt-in script that you could still pull in if you need it - that's also a possible end state.

[Ryan Brown]

On Wed, Jul 20, 2022, 12:55 PM 'Steve Hicks' via Closure Library Discuss <closure-lib...@googlegroups.com> wrote:

On Wed, Jul 20, 2022 at 1:15 AM Ryan Brown <ry...@derivita.com> wrote:

On Tue, Jul 19, 2022 at 7:20 PM 'Steve Hicks' via Closure Library Discuss <closure-lib...@googlegroups.com> wrote:

Short answer: the debug loader is not going away any time soon, but we'd like to get rid of it someday.

Longer answer: while Closure Compiler is a powerful optimizer, it does not provide the best experience for development.  If there's a bug in its sourcemap handling, that would definitely be worth reporting, but overall I'd recommend using vanilla tsc to convert your TypeScript to ES modules, which esbuild can support (at least for development).  To the extent you have any Closure JS, I would recommend migrating it to TypeScript.  Overall, the Closure dependency management system (specifically - goog.provide, goog.require, and goog.module), while revolutionary when it was first introduced, is now a bit of a dead end, and the best bet is to move away from it whenever possible.

That sounds like good advice in general. 

I guess I forgot to mention that our typescript depends on the Closure Library.

So we still need something to handle things like `import Field from 'goog:goog.editor.Field';` 

If you're using Closure Library from TypeScript, I assume you're getting typings from somewhere (I'm aware of a couple external projects that provide .d.ts versions of the library).  I wonder what it would take to transform these libraries into something more standard (i.e. CommonJS, ESM, etc).  It's not something we'd be looking to do (there's a handful of particularly sticky goog.provide files that we're stuck with due to thousands of usages in our codebase, but if you're not cleaning up the world, it should be quite a bit more tractable), but it could bridge some gaps and allow better interop with esbuild and others.  And an approach that sat on top of the library with a repeatable transformation would have the benefit of tracking any upstream changes we push pretty trivially (IIUC that's how the .d.ts versions already work).

We use clutz to generate typings. It's kind of a pain since the last open source release was two years ago. We have to do some hacking to get it to parse files using new syntax.

I believe there's another fork that has a subset of closure library converter to es6 modules and includes typings. I'm not sure how they get their typings.

In a different direction, I wonder if you could take inspiration from the webpack plugin to make something that would work directly with esbuild?

It does seem like an esbuild plugin is possible, but it would need to translate the closure js files to es6 or CommonJs modules that esbuild understands.

I also took another look at the closure compiler source. It seems like that bundler has support for source maps, it's just not hooked up to command line flags. So I may try fixing that too.

Anyway, this isn't an urgent issue - it'll be at least a year or two before we're even close to thinking about doing anything with the debug loader, and there's also a possibility of just spinning it out of base.js so that it's a separate opt-in script that you could still pull in if you need it - that's also a possible end state.

--

---
You received this message because you are subscribed to the Google Groups "Closure Library Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-library-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-library-discuss/CAABDHWZZgAzKxFyEL1S7NA3hDw%3DkZ6Bis0ZvO3geYNkk6%2Bh66w%40mail.gmail.com.