import * as X from 'goog:goog.array';
--
---
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/2b99dcfe-2797-446a-bad1-309da81babca%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-library-discuss+unsub...@googlegroups.com.
On the Closure Library side, we're working on migrating the core to TypeScript and are interested in learning about how folks are using the open-source library that might influence what we could do to make it usable for other workflows and project structures (e.g. loading via NPM vs git submodules, debug loader vs bundler, etc).
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/2b99dcfe-2797-446a-bad1-309da81babca%40googlegroups.com.
--
---
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/73b34392-79fd-42f7-8c9b-951ad2dc08fc%40googlegroups.com.
--
---
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/8a2d99fa-478f-47b8-9eee-2efb354231e0%40googlegroups.com.
The full picture is still developing, but we're considering it a firm requirement that Closure JS sources be shipped in some form usable with Closure Compiler by existing users, without requiring TypeScript, tsickle, or clutz. Likely this will involve using tsickle as part of the build/publish process. That said, we do want to get away from including generated files directly in the GitHub master, so it's not clear exactly where these would live. Possibilities include (1) an NPM package, (2) a separate GitHub branch that can be pushed via CI, or (3) downloadable as an archive. Do any of these options work better or worse for anyone? Ultimately we want to make sure that the master sources are in TS and usable by idiomatic TS workflows, but are committed to keeping Closure-optimizable JS sources available for the foreseeable future.
On Tue, May 5, 2020 at 8:36 AM David Nolen <dnole...@gmail.com> wrote:
On Monday, May 4, 2020 at 7:17:37 PM UTC-4, Stephen Hicks wrote:--On the Closure Library side, we're working on migrating the core to TypeScript and are interested in learning about how folks are using the open-source library that might influence what we could do to make it usable for other workflows and project structures (e.g. loading via NPM vs git submodules, debug loader vs bundler, etc).What is the migration strategy for Closure Compiler users that previously expected to consume GCL trivially? Will we need to run TypeScript first and then only use Closure Compiler for production builds? For users who integrated more tightly with Closure Compiler for custom workflows, would you first transpile all of GCL to a form suitable for Closure Compiler consumption? Or will you all provide GCL both as TypeScript and a form that is GCC ready? Just wondering how tree shaking is supposed to work in this context, etc.Thanks,David
---
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-discuss+unsub...@googlegroups.com.
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/8a2d99fa-478f-47b8-9eee-2efb354231e0%40googlegroups.com.
--
---
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/75cc6757-8b6d-4906-8f95-451d2f32a665%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-library-discuss/CAABDHWZgGf4Sdnaa1ShfSURES8rTjGaSenuzaU5sjtAzfUV2Aw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-library-discuss/CAPC9OaddR0m3xg5kA9YiOy_9Z_6Eo0Es-o%3DoBFYtvROeQ0%3DrDQ%40mail.gmail.com.
We've recently been mining the https://libraries.io data to get a sense of who is using Closure Library outside of Google. Currently we're able to see a number of packages via NPM and Bower, but no results via Maven yet - is there a standard package folks use for this? I see a shell script in the clojurescript repo to build and deploy a Maven release - I assume you do this centrally and users all pull in whatever you're deploying to? Do other JS libraries that ClojureScript users use release their own Maven packages, or do you have similar treatment for any other commonly used JS libraries?Thanks,steve
On Sat, May 9, 2020 at 2:05 PM David Nolen <dnole...@gmail.com> wrote:
Yes, ClojureScript users are JVM users.David
On Fri, May 8, 2020 at 3:23 AM 'Steve Hicks' via Closure Library Discuss <closure-lib...@googlegroups.com> wrote:
Closure Compiler is indeed released on Maven (I assume this is the same thing you're talking about). It's a pretty painful process and doesn't seem particularly idiomatic for JS. Is ClojureScript's dependence on Maven an artifact of Clojure being a JVM language?
On Thu, May 7, 2020 at 6:55 AM David Nolen <dnole...@gmail.com> wrote:
A regular Maven Central release would be most welcome - even better if it was aligned with Closure Compiler releases. We've been bundling our own releases for years :)
David
On Tuesday, May 5, 2020 at 7:13:55 PM UTC-4, Stephen Hicks wrote:
The full picture is still developing, but we're considering it a firm requirement that Closure JS sources be shipped in some form usable with Closure Compiler by existing users, without requiring TypeScript, tsickle, or clutz. Likely this will involve using tsickle as part of the build/publish process. That said, we do want to get away from including generated files directly in the GitHub master, so it's not clear exactly where these would live. Possibilities include (1) an NPM package, (2) a separate GitHub branch that can be pushed via CI, or (3) downloadable as an archive. Do any of these options work better or worse for anyone? Ultimately we want to make sure that the master sources are in TS and usable by idiomatic TS workflows, but are committed to keeping Closure-optimizable JS sources available for the foreseeable future.
On Tue, May 5, 2020 at 8:36 AM David Nolen <dnole...@gmail.com> wrote:
On Monday, May 4, 2020 at 7:17:37 PM UTC-4, Stephen Hicks wrote:--On the Closure Library side, we're working on migrating the core to TypeScript and are interested in learning about how folks are using the open-source library that might influence what we could do to make it usable for other workflows and project structures (e.g. loading via NPM vs git submodules, debug loader vs bundler, etc).What is the migration strategy for Closure Compiler users that previously expected to consume GCL trivially? Will we need to run TypeScript first and then only use Closure Compiler for production builds? For users who integrated more tightly with Closure Compiler for custom workflows, would you first transpile all of GCL to a form suitable for Closure Compiler consumption? Or will you all provide GCL both as TypeScript and a form that is GCC ready? Just wondering how tree shaking is supposed to work in this context, etc.Thanks,David
---
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-discuss+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-library-discuss/8a2d99fa-478f-47b8-9eee-2efb354231e0%40googlegroups.com.
--
---
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-discuss+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-library-discuss/75cc6757-8b6d-4906-8f95-451d2f32a665%40googlegroups.com.
--
---
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-discuss+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-library-discuss/CAABDHWZgGf4Sdnaa1ShfSURES8rTjGaSenuzaU5sjtAzfUV2Aw%40mail.gmail.com.
--
---
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-discuss+unsub...@googlegroups.com.