Clojurians
#cljs-dev
<
2017-12-05
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

juhoteperi11:12:20

@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

juhoteperi11:12:47

Has anyone tried to upgrade Closure compiler to v20171023+?

thheller11:12:04

I did yeah, needs a change in cljs.closure

thheller11:12:19

forgot which but a warning mapping was removed

juhoteperi11:12:04

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

thheller11:12:49

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

thheller11:12:23

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

juhoteperi11:12:06

Is there issue about upgrading Closure?

juhoteperi11:12:34

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

juhoteperi13:12:54

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

juhoteperi14:12:54

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

thheller14:12:21

they have no effect in the browser

thheller14:12:48

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

thheller14:12:47

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

thheller14:12:12

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

thheller14:12:39

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

juhoteperi14:12:49

Looks like cljs_deps.js is missing requires for Node modules

thheller14:12:35

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

mfikes14:12:16

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

dnolen15:12:08

@mfikes we should effectively ignore to support portability yes

dnolen15:12:25

maybe warn on ^long

mfikes15:12:31

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

mfikes15:12:49

I'll add your note about ^long

favila15:12:34

Honestly I usually have the opposite problem

favila15:12:08

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

favila15:12:41

Could ^Boolean in cljs alias ^boolean?

favila15:12:50

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

dnolen18:12:55

I’m OK with that, patch welcome

dnolen18:12:23

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

dnolen18:12:31

--debug -> --inspect

richiardiandrea19:12:29

@dnolen there was a patch already for that

dnolen19:12:44

oh missed that, link?

richiardiandrea19:12:45

sorry my fault I was not pushing it :smile: