What is the current recommended module system for developing applications with closure library?

[jimbojetlag]

As of now closure compiler is able to to handle a few different js modules, including:

1. goog.prodive/goog.require
2. goog.module
3. ES6 modules
4. Common JS

But when it comes to developing with closure library, only the first 2 are supported. Recently, the javascript implementation of dependency maker, closure-deps made the 3rd option possible.

It is not clearly documented that which approach should a greenfield project that depends on closure library take when it comes to modules. Is ES6 modules the future of applications built with closure library?

Are there any reasons to use goog.provide for new projects, including any performance/optimization gains?

[jplaisted]

So, this is complicated. Closure Library hasn't yet to wholly move to goog.module yet, or even has wide use of ES6+ features. The library will always (sadly) be behind due to it needing to support the lowest common denominator.

For your own project I think it highly depends on your situation. Are you a leaf project, and no one depends on you? If so, you can use whatever module format you like! My personal opinion would be ideally ES modules, though if you have a better developer setup or IDE that works better with something else, go for that. Whatever makes you most productive, followed by whatever is standardized. This may also include TypeScript via tsickle and clutz.

If your project is not a leaf, meaning you have projects depending on yours, you need to take them into consideration and what they support. ES modules are still not widely supported in the wild. Examples: Still not supported in Node (well, it's behind a flag...), browser support is there, but not terribly ergonomic due to only supporting relative paths (import maps hopefully eventually solve that), etc. Though you may be able to get around this by transforming your source code to a module format that is supported widely, e.g. write in ES modules but use webpack to provide a single, non-module bundle. Or babel to UMD/CJS with RequireJS, etc.

For the time being it doesn't matter what your source code is in, in all cases you will use goog.require to get access to Closure Library, as it is currently all goog.provide and goog.module files (or import 'goog:namespace' in TypeScript).

@concavelenz @shicks @nreid260 may have more thoughts or guidance.

[jimbojetlag]

Thank you @jplaisted. How is it possible to use Closure Library in Typescript today? It seems like Clutz has not been applied to Closure Library, or at least the resulting d.ts files are not open sourced.

Would the existing deps.js of Closure Library be enough to use the library, or would it need dynamic dependency generator? Is there a minimal example project to demonstrate this?

[jimbojetlag]

This issue angular/clutz#755 by @gregbown demonstrates that Clutz cannot be successfully used to generate .d.ts fo Closure Library. The issue remains unanswered.

Given that Clutz was created to target Closure annotations, it is ironic that both Clutz and Closure Library are open sourced, but the resulting Typescript definitions are not!

[jplaisted]

I believe the idea is that clutz should be used to generate the .d.ts files on the fly. I was not aware of that issue, thank you for bringing it to my attention. I'll reach out to the Angular folks and talk with them about it.

[jimbojetlag]

I believe the idea is that clutz should be used to generate the .d.ts files on the fly.

When using Closure Library as a static library, wouldn't the .d.ts files be also static, similar to the generated deps.js that comes with Closure Library?

Sorry to ask this question again, what is the workflow for developing a (leaf) application in Typescript that uses Closure Library? I can see Clutz must be used to generate the .d.ts files, does that mean that from that point Closure Library can be used just like a Typescript library, or does it still require Closure Library specific module loaders during development?

[jplaisted]

When using Closure Library as a static library, wouldn't the .d.ts files be also static, similar to the generated deps.js that comes with Closure Library?

If you're using an npm release, yes. If you constantly sync to head, no. Closure Library is only as static as you want it to be :)

I'll discuss within the team if we should provide these files with our release.

Sorry to ask this question again, what is the workflow for developing a (leaf) application in Typescript hat uses Closure Library? I can see Clutz must be used to generate the .d.ts files, does that mean that from that point Cosure Library can be used just like a Typescript library, or does it still require Closure Library specific module loaders during dvelopment?

No worries! @mprobst should be able to comment more here. I believe it may force you into using tsickle (which will compile your TypeScript to goog.module files), but I am not 100% sure.

As far as source code goes, I believe should be able to use a special import syntax in your TypeScript files. If your import specifier is goog:namespace, then that should import the Closure namespace.

import * as googArray from 'goog:goog.array';

[mprobst]

@jplaisted is right, you'll need to use tsickle (https://github.com/angular/tsickle) to compile your code, which emits goog.module code, and then on the client side, it's using the Closure module system to bind everything together.

I'm afraid we don't have a very well trodden setup for all these bits together, and you might encounter some trouble with tsickle and the path names it generates. We haven't seen a lot of people using Closure together with TypeScript outside of Google yet.

[jplaisted]

So stemming from #937, I took a look at JsAction. They publish some pre-built code you could use. If that's all that you need, and don't want to use the Closure Compiler or Library, I'd recommend using those files.

If you want to use the Closure Compiler then you should probably write ES modules or goog.modules (goog.provide is super old and is in the global scope). You could try using TypeScript with the Closure Compiler via tsickle and clutz, though I don't think we have a well worn path around this for small external projects yet (like having a super fast edit / refresh dev flow). If you want to use TypeScript but not the Closure Library/Compiler, then there's no reason to use clutz or tsickle, just use the minifed / prebuilt JsAction files. They should be super simple to write some .d.ts files for, if they don't already exist.

So fundamentally this all depends on your use case. What combinations Closure Library, the Closure Compiler, JsAction, and TypeScript did you want to use?

[jimbojetlag]

I took a look at JsAction. They publish some pre-built code you could use. If that's all that you need, and don't want to use the Closure Compiler or Library, I'd recommend using those files.

You are right. However, the precompiled files are more or less for demo purposes. For anything nontrivial, you will have to define your own dispatch handler which would require the use of Closure Library and Closure Compiler.

One option is to develop some minimal code that depends on jsaction in Closure Scripts (goog.provide), or Closure modules (goog.module), which will be compile by Closure Compiler and used as a library by the main application written in ES modules. This would require the small library calling jsaction to be a project of its own.

Another option would be to use an environment that both Closure Scripts and ES modules can be used together. This helpful demo of closure-webpack-plugin shows that this can be made possible by Webpack loader. There seem to be some overlapping between this Webpack plugin and closuremakedeps.js in this repo, they both make it possible to mix ES modules with Closure Scripts.

I guess the optimum setup for an application that uses Closure Library is the one that the developer can use the above mix modules, and yet be able to compile the code down to the Closure Compiler annotated version for best optimizations in production. It seems to me that closure-webpack-plugin is able to provide that environment. It would be good to have that plugin in referenced Closure Library wikis.

Overall, the external developer experience for using Closure Library, and libraries that depend on it, remains poor, and not having an improving trend. When Closure Compiler was first open sourced, there was only one way of developing apps with it: Closure Scripts. Now there are many combinations, and making decisions about them is not easy, sometimes leading to impossible situations. For example, you can see in google/closure-templates#169 how the side effect of compiling Typescript to Closure Script led to unopensourcing the Incremental DOM Soy compiler.

[shicks]

This issue is being closed as a preparation step before archiving the repository. See the README for more detail.