@thheller When I last looked into how Chad was going to solve this, Closure will export the object both as module$something AND module$something.default, so both ES6 and CJS requires work

Has anyone tried to upgrade Closure compiler to v20171023+?

I did yeah, needs a change in cljs.closure

forgot which but a warning mapping was removed

I think it will requires other changes also, to fix how dependency information is read from processed modules, as Closure doesn't emit goog.require/provide calls anymore, for processed modules

yeah no idea about that as that already works entirely different in shadow-cljs

about the .default thing though I think they removed that and settled on the ES6 style only

Is there issue about upgrading Closure?

I do have some code ready for maybe fixing the module dependency information stuff

Looks like I opened one already: https://dev.clojure.org/jira/browse/CLJS-2389

Something in the analyzer is probably also looking at goog.provide, but maybe emiting that call ourselves is okay (easiest fix)

Looks like goog.provide and goog.require are anyway required for loading the files in browser

they have no effect in the browser

well goog.provide does ensure the obj exists, require is a noop

Hmm strange

closure uses it to sort dependencies so it may be required there

but the way the closure debug loader works goog.require itself can’t load the file but the file must have been loaded before

so goog.require itself does nothing IF the file is already loaded

Looks like cljs_deps.js is missing requires for Node modules

yeah that part controls the debug loader so that needs to know proper requires/provides

Do we generally take the stance of ignoring Clojure type annotations? (I thought I saw that pattern before in the compiler.) An example of where we aren't is code like this:

cljs.user=> (if-let [^int v (alength (into-array []))] (+ v 3))
WARNING: cljs.core/+, all arguments must be numbers, got [int number] instead. at line 1 <cljs repl>
3

@mfikes we should effectively ignore to support portability yes

maybe warn on ^long

OK, I'll log a JIRA for this particular example

I'll add your note about ^long

https://dev.clojure.org/jira/browse/CLJS-2435 for ^

Honestly I usually have the opposite problem

Need to add Boolean hint to cljs, but clj doesn’t like it

Could ^Boolean in cljs alias ^boolean?

I end up writing #?(:cljs ^boolean mysym :default mysym) often

I’m OK with that, patch welcome

I noticed latest Node.js breaks Node REPL, I pushed a fix - I think we were using an old flag so hopefully this doesn’t break 0.6.X users

--debug -> --inspect

@dnolen there was a patch already for that

oh missed that, link?

sorry my fault I was not pushing it 😄

@dnolen https://dev.clojure.org/jira/browse/CLJS-2362