Fork me on GitHub

@dnolen Yeah... I may try running stuff locally... (last time I looked Travis did this thing where they gave out free credits and those expired for the Canary system)


@mfikes hrm do they have exception for open source projects? I suppose we could move it GitHub has well?


I have good experiences with OSS + #circleci as well (if Github isn't powerful enough for some reason)

👍 2

@dnolen Yeah, Travis has exceptions for OSS... and you evidently have to request more tokens when you run out. Last time I looked Canary tokens owned by Antonin may have run out.


well if anyone has free time - please give the branch above a spin - it's possible there are other changes to Google Closure Library that we don't capture in our tests


the big change is that we just always load goog.module namespaces in the "right" way


we forced into this as a couple of namespaces we use dropped the legacy support (code splitting stuff being the important one, that all works again in the branch)


on the way - I went ahead and added var parsing for goog.module namespaces, so basic var checking, type inference should work for both kinds of Closure namespaces


context for the Closure Compiler team souring on ES module support


it looks like there just too much sunk cost into goog.module so hopefully this set of ClojureScript changes gets us stabilized for at least another couple of years


@dnolen that thread is specifically about import maps, which is a way to define remapping for urls. That's largely a spec that exists for making code splitting/caching possible.


Oh, I see your point now. If they're not expanding into import maps, they're likely not expanding into other things. Got it.


They clearly state a general limited interest not specific to import maps


This clarifies some older conversations because this would mean no general move to es 6 modules is planned which was not clear before