Fork me on GitHub
#clojurescript
<
2017-02-27
>
mruzekw01:02:44

I’m trying to import a node ES6 module, and it doesn’t know what to do with the spread operator: Is there anyway to add a preset to the Closure Compiler to let it know what to do with it?

anmonteiro01:02:10

@mruzekw how are you trying to import a node ES6 module?

mruzekw01:02:25

:foreign-libs

anmonteiro01:02:36

can you show me your foreign lib entry for that module?

mruzekw01:02:06

:foreign-libs [{:file "node_modules/react-scroll-horizontal/src/react-scroll-horizontal.js"
                                      :provides ["com.mruzek.hz-scroll"]
                                      :module-type :es6}]}

anmonteiro01:02:20

@mruzekw did you add :language-in :es6 to your compiler options?

mruzekw01:02:38

Where would I put this?

anmonteiro01:02:44

ClojureScript compiler options

mruzekw01:02:55

I have now

anmonteiro01:02:09

did that fix the issue?

mruzekw01:02:15

Calculating...

mruzekw01:02:21

Isn’t that the target compilation?

mruzekw01:02:28

It didn’t fix the issue

mruzekw01:02:58

I’m getting:

ERROR: JSC_PARSE_ERROR. Parse error. '}' expected at node_modules/react-scroll-horizontal/src/react-scroll-horizontal.js line 96 : 6

mruzekw01:02:23

Looks like “Babel Transforms” is what I’m looking for https://clojurescript.org/guides/javascript-modules

anmonteiro01:02:35

I don't know if ES6's specification includes the rest operator

anmonteiro01:02:43

in any case the transform should help you

mruzekw01:02:04

Now I’m getting missing module errors:

ERROR: JSC_COMMONJS_MODULE_LOAD_ERROR. Failed to load module "react" at react-scroll-horizontal.js line 5 : 21
ERROR: JSC_COMMONJS_MODULE_LOAD_ERROR. Failed to load module "react-dom" at react-scroll-horizontal.js line 5 : 39
ERROR: JSC_COMMONJS_MODULE_LOAD_ERROR. Failed to load module "react-motion" at react-scroll-horizontal.js line 5 : 61

mruzekw01:02:22

Any idea how to map from a commonjs module definition to a closure module?

anmonteiro01:02:09

@mruzekw if you're consuming node modules you should be aware you're trying out pre-alpha features and expect to figure things out on your own

anmonteiro01:02:52

your could probably use cljs.build.api/node-inputs to calculate the dependencies for your module

mruzekw01:02:15

Hmm, thanks

qqq02:02:13

are there any om <-> webgl bindings available? I'm aware of gamma and http://thi.ng, but they both seem to be pure cljs

anthony.naddeo02:02:17

Does anyone have any experience creating commonjs libraries with clojurescript?

anthony.naddeo02:02:29

I'm attempting to use clojurescript on AWS lambda

anthony.naddeo02:02:52

and I'm not sure how to get an exports.handler into the top level of the build

stbgz02:02:07

on a different note. calvin-cljs got an update to support the lumo.build.api https://github.com/eginez/calvin

anthony.naddeo02:02:26

@stbgz Thanks! looking into that now

qqq03:02:45

Is there a simple om-next example where as I move mouse cursor around, the x/y coordinates are updated?

qqq04:02:07

@anmonteiro : this is precisely what I needed; thanks!

robert-stuttaford06:02:45

show-stopper cljs advanced compilation bug with core.async http://dev.clojure.org/jira/browse/CLJS-1954, due to async being a new reserved word

qqq11:02:21

When something works perfectly fine in :optimizations :none, but gives an error of "cannot read property 'j; of undefined" under :optimiozations :advanced .... how do I debug this?

deas11:02:39

@anmonteiro fwiw, can no longer reproduce the closure naming issue. Think it was somehow related to npm link. Will sort it out in case it hits me again.

qqq11:02:19

weird, a few recompiles later, it all works, looks like something was stale

robert-stuttaford12:02:09

@qqq :pseudo-names true + :pretty-print true gives you :advanced without the senseless names, so that you can read it

qqq12:02:16

@robert-stuttaford : I'm sorry how do debug with this, is it: 1) in :compiler-options : 1a) remove :optimizations :advanced 1b) add :pseudo-names true // add :pretty-print true 2) rerun program 3) then, when error pops up, I somehow map pseudo-names back to real clojure names? The part that confuses me is as follows: if the names are accurate, I should ahve no problem since :optimizations :none works if the names are not accurate, how do I guess the original names?

henriklundahl12:02:35

@qqq, you should keep :optimizations :advanced

henriklundahl12:02:09

Clean up generated js and compile.

qqq12:02:18

okay, this makes sense, so it does all the optimiozations; but instead of minifying everything down to 1-letter var names, it gives me pseudo names that should be reversible

arttuka12:02:58

@qqq: are you using a javascript library and forgot externs?

qqq12:02:22

I don't know what happened to be honest.

qqq12:02:28

I tried to debug it, and it vanished.

qqq12:02:37

No, I'm not manually importing any *.js libs.

qqq12:02:42

I suspect there was some caching issue.

Aron12:02:45

i really hoped that all the caching issues are in the past 🙂

Aron12:02:48

and i really do not understand why they are not yet solved in this environment

darwin12:02:17

"There are only two hard things in Computer Science: cache invalidation and naming things.” -- Phil Karlton

qqq13:02:21

Every problem in CS can be solved wiht an extra layer of indirection; except the proble of having too many layers of indirection.

fernandohur13:02:03

@darwin "There are only two hard things in Computer Science: cache invalidation, naming things and off by one errors.” -- Anonymous

mobileink19:02:35

fernandohur: genius!

Aron14:02:26

just because someone said something that we consider more or less true

Aron14:02:46

it doesn't change the situation that before i started working with clojurescript, i have not head these cache errors for years

Aron14:02:28

not saying it was easy, just that it was abstracted away and the problem did not arise unless you specifically tried to deal with it

Aron14:02:22

definitely didn't arise in situations like using a development environment where all caching should be always turned off (unless you want to work on a cache or with a cache, but again, those are specific scenarios, not everyday situations)

Aron14:02:05

because of this, i find it hard to believe that this is about caching

thheller15:02:04

@ashnur the caching we are talking about here is exactly what you want turned ON during development

risto15:02:12

what's generally the size of a large clojurescript app with advanced compilation and gzipped that people have seen?

thheller15:02:23

turning if off would significantly slow down your development experience

thheller15:02:42

that being said I had no issue with caching with a few years now

thheller15:02:19

if just has become one of those "did you try turning it off and on again?" type things where restarting usually resolves the thing

thheller15:02:29

whether caching was actually involved is unknown

thheller15:02:59

@risto completely depends on what you are doing and how complex your app ist

tbaldridge15:02:37

@risto I worked on a app that had 30MB of JS files, gzip+advanced compilation = 400KB

tbaldridge15:02:55

(JS files = output of CLJS compiler)

risto15:02:01

have you had any issues with closure compiler specific things for that large app?

tbaldridge15:02:21

not really, it all worked really well

tbaldridge15:02:03

turning on simple optimizations helped performance a lot, as well as advanced compilation (although perhaps less of a improvement moving from simple->advanced).

tbaldridge15:02:07

I would recommend doing all benchmarking and performance testing with optimizations turned on. It sounds like a 'duh' suggestion, but those compilation modes improved performance of some of our functions by 10x.

niwinz15:02:18

@risto I'm working on app that has 5Mb of js files, but passes to be 450k advanced+gzip or 320k advanced + brotli 😉

risto15:02:52

that's interesting

isak15:02:50

because it can be hard to keep access consistent across a big codebase. Sometimes you may need aget, but sometimes not

risto15:02:10

@niwinz I'm wondering what made your compression level much less than @tbaldridge (400KB/30MB vs 450KB/5MB)

tbaldridge15:02:56

@risto it's dead code removal

niwinz15:02:07

Maybe I have less dependencies and I'm using bigger portion of code of that dependencies. The dead code removal on the end depends on each codebase..

tbaldridge15:02:30

the Closure compiler removes code that's included in your project but never actually called. My project had a fair amount of cruft

risto16:02:10

ah makes sense

rauh16:02:21

@risto About 17k LOC cljc+clj(macros)+cljs -> 160kb gziped. Excl. React

risto16:02:19

rauh how many mb was it?

rauh16:02:24

My recommendation is: Keep your dependencies to a minimum.

rauh16:02:02

I have Datascript, Bidi and Rum. Nothing else. The rest is all goog.*

Aron16:02:15

@thheller are you saying that hmr is impossible to solve on the level as incremental compilers (like browserify for example, where i think there is hmr, but i never tried, it was enough that the bundle was finished in miliseconds)

Aron16:02:53

afaik no incremental compiler in javascript has these kinds of "cache issues" that i am also experiencing (exclusively with clojurescript)

negaduck16:02:38

hello. How to check if goog.DEBUG is set as early as possible? I want to have some bindings in index.html. Or how to compile index.html without debugging code?

thheller16:02:04

what is HMR?

Aron16:02:12

hot module reload

thheller16:02:24

ah no not what I'm talking about. The caching I'm talking about is the analyzer cache. The analyzer keeps all information about your CLJS code, ie. which namespaces exists, which functions and so on.

thheller16:02:33

this is required for compilation, so if that somehow gets out of sync you are compiling against stale data

Aron16:02:05

i used incremental compilers in javascript for years without any kinds of cache issues

thheller16:02:52

again: I have not run into any actual cache issues for years now as well

thheller16:02:11

running lein clean is just the go to suggestion for ANY problem

thheller16:02:28

this is why it comes up often. whether or not caching was actually the problem is unclear

Aron16:02:38

1. you were one of those who said this is so common, you are guessing just to be sure 2. i always run lein clean && lein figwheel but that doesn't really help much 3. running lein is very slow. i must say that the develoepr enviroment (with or without hot reload) is a serious downgrade from what i am used to in javascript.

thheller16:02:40

@negaduck you maybe want to look into :closure-defines as a compiler option, that allows you to define goog.DEBUG for your build

thheller16:02:41

@ashnur so ... if you want to start that subject, I need to make a disclaimer: I wrote shadow-build which is basically a replacement to any other build tooling you might have used. ie lein-cljsbuild and lein-figwheel. I won't comment on any of these as I haven't used them in over three years.

thheller16:02:35

I wouldn't recommend my build tooling to anyone (yet) as documentation sucks but one of the reasons that motivated me to start all of it was performance and caching errors

thheller16:02:37

so my judgement about caching errors may actually be incorrect I only know that I fixed all the issues I could find

anmonteiro17:02:04

@ashnur lein clean might not do what you think it does

anmonteiro17:02:03

it’ll clean your build only if it’s listed under :clean-targets in your project.clj

Aron17:02:03

will check it when i have time again to learn cljs

thheller17:02:26

@anmonteiro I have to say though: every time you actually run lein clean and a CLJS problem goes away that probably was a bug in CLJS. So I'm very unhappy that this is still a suggestion that is made frequently.

anmonteiro17:02:17

My comment was only about a particular feature of Lein that may be misleading to users

thheller17:02:47

yeah I know, just saying that you should never need to run it

anmonteiro17:02:58

@thheller I haven’t actually used Lein for more than a year, and I haven’t had any issues since then

anmonteiro17:02:13

most likely because Boot caches a lot less

anmonteiro17:02:36

which I understand may also not be the solution

thheller17:02:27

I never used boot so I can definitely not comment on that situation

Aron17:02:48

you know, there are way more build tools in js i think than in cljs, yet most people tried all of them for some time (well, most people who are working with js more than 6 six years, not beginners, of course)

anmonteiro17:02:53

I don’t know what that is supposed to mean

Aron17:02:31

nothing special. i find the irony somewhat amusing

thheller17:02:12

what irony?

anmonteiro17:02:24

@ashnur I suppose that’s a theme better suited for #off-topic if it’s not related to ClojureScript or adding anything to the conversation

mruzekw17:02:41

I’m trying to build in a foreign-lib and I’m getting the following error from the compiler:

Cannot build without root node being specified
Anyone have an idea what’s up?

anmonteiro17:02:12

@mruzekw that means your module has an error being processed

anmonteiro17:02:21

I discovered last night that these errors are getting swallowed

anmonteiro17:02:43

@mruzekw actually glad you reminded me, just submitted a patch for it http://dev.clojure.org/jira/browse/CLJS-1957

mruzekw17:02:35

If a foreign lib uses UMD do I need to specify a :module-type?

:foreign-libs [{:file "react-scroll-horizontal.js"
                        :provides ["cljsjs.scroll-horizontal"]
                        :requires ["cljsjs.react-motion"]}]}

mruzekw17:02:26

Okay I didn’t think so. I’m getting a null pointer exception, though

mruzekw17:02:34

Does that mean it can’t find the file?

mruzekw17:02:17

I can paste the stack trace if you like

anmonteiro17:02:02

@mruzekw sorry that stack trace doesn’t mean anything to me. I’m happy to look at a repro which doesn’t include Figwheel or Sierra’s component

anmonteiro17:02:44

there’s just no useful information in that stacktrace

mruzekw17:02:47

Alright, no worries. I’ll see what I can find myself

leroix19:02:03

@tbaldridge how long did your page loads take in local dev with 30MB of js? We’re at 18MB and it takes 8-9s.

tbaldridge19:02:40

that's about right 15sec or so, with adv compilation it was almost instant.

tbaldridge19:02:28

I would not recommend having that much JS...this was a worst-case situation, and I wasn't really in a position of power to demand a code-cleanup of the unused deps.

leroix19:02:50

gotcha, yea, I’m in the process of bringing that down

leroix19:02:12

found out that we’re loading cljs.js which is 4.5MB by itself

tbaldridge19:02:16

That being said, with figwheel + react we didn't have to reload the app often. I probably reloaded once an hour or so when I was really digging into a bug.

leroix19:02:46

it was for a dev tool, so I can easily cut it

leroix19:02:18

code reload is nice, but I find fast page (re)load to be an absolute must

anmonteiro19:02:21

@leroix if you’re loading cljs.js there are some other tricks you can do to lower the bundle size

anmonteiro19:02:57

for example: :dump-core false in your compiler options and lazy-load the analysis cache

leroix19:02:36

does that require optimizations?

anmonteiro19:02:21

you can use with / without optimizations

leroix19:02:17

nice I’ll check it out

leroix19:02:19

btw, I don’t know if many people realize this but a hefty part of the initial compilation time for cljs comes from lein. If you just run

java -cp cljs.jar:src clojure.main build.clj

leroix19:02:35

on a project, it’s actually pretty fast

leroix19:02:47

I realize there are other reasons people don’t like the jvm

richiardiandrea19:02:47

@leroix also relevant, on we were able to compress our main.js to 707kb (gzipped)

leroix19:02:37

@richiardiandrea nice, what was it without gzip and advanced optimizations?

richiardiandrea19:02:54

@leroix no, advanced is not possible in cljs-in-cljs

leroix19:02:59

ours goes from 9MB (advanced) to about 900k gzip'd

richiardiandrea19:02:29

:dump-core false is a must, and you load the cache on load

richiardiandrea20:02:01

plenty of examples now among planck, lumo and replumb now, I am happy cljs-in-cljs is taking over 😄

leroix20:02:17

One thing I’ve been curious about is packaging cljs modules as npm modules. I wonder if cljs-in-cljs makes that a lot more feasible

richiardiandrea20:02:30

@leroix for cljs libs I created a boot task at the time: https://github.com/Lambda-X/boot-pack-source

richiardiandrea20:02:54

it takes the sources and put them in a folder on the boot fileset

richiardiandrea20:02:17

that folder is dumped then on the server (in case of a website deploy)