@lee how? re: ns clashes? Is there a link somewhere to how moving away from goog.provide would solve that?

@lee not really interested in jsvu

affordances like that for devs is just not high priority

and not interested in pulling in more stuff when installing JS engines is not that hard

@dnolen, my question on ns clashes is out of pure ignorance - and by ns clashes, I mean things like a.b.c clashing with a.b/c in cljs due to way namespaces are represented in Google Closure . Within the ClojureScript Podcast on Google Closure they touched on one of the reasons for goog.provide deprecation is the use of globals. This made me wonder if the use of globals is related to the namespace clash problem and if using modules would in any way help here.

@dnolen re jsvu - I think I’ll use it because I found getting WebKit engine on linux and windows mystifying and building v8 more involved than I’d like, especially on Windows. But I do appreciate that changes (and reliance on 3rd party tools) have a risk/cost and can close the JIRA issue I created.

And… I do sincerely appreciate you letting me know you aren’t interested in jsvu… saves me from wasting effort.

It feels like ending externs inference guide with this part in https://clojurescript.org/guides/externs#return-types is a bit confusing. What this warning is about? Does it mean that it’s safe to ignore it?

@roman01la the warning is precise

we propagate type information

and check that an externs exists for some property you want to use

if it warns in that particular case maybe that property doesn't exist

so you have an interop problem

@lee jsvu, no worries

@lee well that makes two of us re: goog.provide - I wasn't aware that the new modules stuff solves the global ns issue?

oh ok , found this one also https://clojure.atlassian.net/browse/CLJS-2928

@dnolen, re goog.provide - I don’t know enough to answer if new modules stuff solves the global namespace issue but maybe? https://github.com/google/closure-library/wiki/goog.module:-an-ES6-module-like-alternative-to-goog.provide

@lee yeah I think the description is misleading

re: goog.module

what they're talking about wrt. to "global" is top level var

but we don't do that anyway since nobody is writing JS by hand

far as I can tell the benefits are entirely from the perspective of someone writing JS directly

thanks @dnolen

@dnolen if I understand correctly the closure compiler folks will deprecate goog.provide/require entirely and move to path based es6 style import/export

but not for a while I guess