provide/requires in css files

128 views
Skip to first unread message

Peter StJ

unread,
May 1, 2020, 4:50:56 AM5/1/20
to Closure Library Discuss
Recently I have notices that provide/require annotations (and as of today - out of comments as well - see https://github.com/google/closure-library/commit/4958823da8e5f49b26aea31d2db867a4a03794d0) are used in css files.

What is the objective of this, I would suppose it is to be used by a tool, is this tool publically available, does it have any documentation we can take a look at?

As of now we are using less files which are compiled to css in a build step, but are interested in other approach, thus this question.

Thanks.

Stephen Hicks

unread,
May 1, 2020, 5:02:25 AM5/1/20
to Closure Library Discuss
You are very observant.  And you're correct, these are used by a tool.  The Google-internal version of Closure Stylesheets compiler has a dependency management system added onto it, and we run all our CSS files through that internally.  Closure Stylesheets has been unmaintained for some time, and there is now a push to actually migrate these files to Sass.  I'm not familiar with the details of this migration, but I understand that moving these out of the comments is the first step.  After testing that this had no negative effects when loaded uncompiled by browsers, it seemed reasonable to go ahead with pushing the change publicly.

Does this change affect you?  Either way, I'd be interested to hear how you have been consuming these files, in order to better understand what requirements we should maintain.

steve

Peter StJ

unread,
May 2, 2020, 4:24:43 PM5/2/20
to Closure Library Discuss
Thanks you for your answer.

Currently the code is being imported 'manually' in our less files (we use Less as pre-processor including in development and in a build step less is compiled to a single file which is then compiled with closure-stylesheet for minifications, we do not use the GSS extension language at all)

We strugling with a solution that can use css splitting (similar to how chunks/modules work in the compiler), i.e. we need to be able to not load the whole css blob at once but instead split it in one main and several additional css chunks.We can produce several chunks but the renaming does not work at all in this case (i.e. class name minification) and the process is basically manual.

Seeing the movement in css in the library I was hoping a solution would be around the corner :) I have notices that soy templates the 'template' directive have new(ish - not sure from when) option to declare css dependency and I was hoping to use that to produce some sort of list of css namespaces that might be needed and a tool to combine those 'per chunk' or at least not needing to manually include the @import clauses in the app's main less file but instead do it based on the templates.

Anyways I understand that Google has a lot of internal tools that are not available for public consumption, so that is okay. Other areas that we have been looking into was how to write typescript in a way that it would understand importing from goog.module (i.e.
import * as X from 'goog:goog.array';

etc) and then compile it back to javascript (we have a LOT of closure style code) with jsdocs so compiler can use it, but couldn't find a way to make this work either, so basically we are stuck in 5+ years old workflow for now.

Steve Hicks

unread,
May 4, 2020, 7:17:37 PM5/4/20
to Closure Library Discuss
Have you looked into Bazel + Tsickle?  It's not an externally-supported workflow, but we do use it internally for pulling Closure deps into TypeScript in exactly the way you're suggesting.

I can't speak to the specific details of changes (since I'm not really aware of their timeline) but in general there are a number of convergence efforts ongoing which should (very) gradually be moving Google-specific infrastructure more in line with external practices, so do keep an eye out for these.

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).

--

---
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.

Peter StJ

unread,
May 5, 2020, 7:22:00 AM5/5/20
to Closure Library Discuss
Migration to typescript sounds very exciting, to be honest it is kind of a bummer writing pure javascript these days without the constant feedback from the language service and rely on running the compiler (which can be slow tbh). I have used the compiler and the library in a Makefile driven project (where we have the advantage of being able to 'watch' the directory and at least for development be very fast as only changed file trigger deps discovery etc and for the advanced compilation build again - only if some artifacts are newer. I have used them in npm driven project as well (i.e. install library and compiler via npm) but I had to write custom gulpfile to a) be able to build specific namespaces (we have more than one entrypoint) and b) be able to integrate with the rest of the project (polymer 1 built with polymer cli). We ended up writing our own npm package that wraps easy creation of targets for the compiler. Not terribly complicated, but useful to several internal projects https://github.com/pstjvn/gulp-closure-tasks/blob/master/index.js

I have looked as tsickle but could not make it work.

Good look with the migration and hopefully outsiders will be able to require closure library utils in typescript projects and have a seamless build.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-library-discuss+unsub...@googlegroups.com.

David Nolen

unread,
May 5, 2020, 11:36:20 AM5/5/20
to Closure Library Discuss
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

Ryan Brown

unread,
May 5, 2020, 11:57:33 AM5/5/20
to closure-lib...@googlegroups.com
AFAIK you need bazel in order to run tsickle.
You also need clutz to generate typescript type definitions from the closure jsdocs.
I'm currently working on updating https://github.com/derivita/rules_ts_closure/ , but unfortunately we don't have much documentation about how to set it up. These bazel rules handle both tsickle and clutz so that you can have ts code depending on closure js and visa versa.
There is also the gents tool which you can use to convert your closure js files into typescript.

To unsubscribe from this group and stop receiving emails from it, send an email to closure-library-d...@googlegroups.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.

Steve Hicks

unread,
May 5, 2020, 7:13:55 PM5/5/20
to Closure Library Discuss
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.

--

---
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.

David Nolen

unread,
May 7, 2020, 9:55:49 AM5/7/20
to Closure Library Discuss
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.

Steve Hicks

unread,
May 8, 2020, 3:23:42 AM5/8/20
to Closure Library Discuss
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?

To unsubscribe from this group and stop receiving emails from it, send an email to closure-library-d...@googlegroups.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.

David Nolen

unread,
May 9, 2020, 5:05:20 PM5/9/20
to closure-lib...@googlegroups.com
Yes, ClojureScript users are JVM users.

David

Steve Hicks

unread,
May 13, 2020, 5:06:17 AM5/13/20
to Closure Library Discuss
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

Hochhaus, Andy

unread,
May 13, 2020, 10:37:01 AM5/13/20
to closure-lib...@googlegroups.com
Hi Steve,

As one datapoint, we (SameGoal - EdTech company) heavily use closure however all our code is closed source and hence not visible on libraries.io. We use bazel with rules_closure for our builds which fetches the closure-library sources from github archives. It should be easy to update rules_closure to pull from another source.

-Andy

Thomas Heller

unread,
May 13, 2020, 6:05:54 PM5/13/20
to Closure Library Discuss
ClojureScript bundles the raw Closure sources and publishes them to maven as org.clojure/closure-library.

See https://libraries.io/maven/org.clojure:google-closure-library

ClojureScript itself depends on that and uses parts from the closure library directly in its sources.


ClojureScript provides the closure-library dependency so many CLJS libraries use code from it without explicitely depending on the closure-library directly. That might make it difficult to track. It is however accurate to say that every CLJS user also uses the closure-library, just varies how much. ClojureScript libraries are all published via maven, most often via clojars.org.

HTH,
/thomas




On Wednesday, May 13, 2020 at 11:06:17 AM UTC+2, Stephen Hicks wrote:
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.

--

---
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.

--

---
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.

--

---
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.
Reply all
Reply to author
Forward
0 new messages