hello everyone

I have a strange problem when importing an ES6 module in a cljs file.

when trying to call an async function from the ES6 module, the following error appears:

return $jscomp.asyncExecutePromiseGeneratorProgram(function($jscomp$generator$context) { ^ ReferenceError: $jscomp is not defined at Object.authClient$$module$js$oauth2 [as authClient]

…

the js module works like a charm when used by javascript code

I’m really stuck

@thheller I've been using shadow to compile a lambda for an Alexa skill, but I've hit a problem when using the juxt/tick library. It works fine with development compile, but some functions break when compiling for release. I assume something with the optimizations. Release mode does however work fine with browser target, but not with node-script/library. For all I know it could be some problem with the library, but since it worked with the browser target I figured I'd best ask here first. I put together a repro here: https://github.com/AlexSKaye/shadow-cljs-node-release-repro

@rastandy do you require rewriting async/await code to polyfills would it be ok to assume a modern browser target?

the error you get is from missing polyfills. not sure why they are missing but not needing them in the first place would be the easiest solution

@noxdeleo looks like missing externs. in the browser case shadow-cljs processes all the JS and can easily generate the externs

for not that doesn't happen so the externs are missing

I would recommend avoiding that library ...

Ok, thanks.

seriously too much code ...

500kb for just a time lib?

@noxdeleo you can run shadow-cljs check app to get some insights into which externs are missing

Wow, I didn't realise it was quite that big. Running check app gives several hundred warnings. Guess I'm hunting for another library.

yeah check isn't super useful because of the noise it reports

but the last few warnings are from the tick/core.cljc ns

only those matter the rest can probably be ignored

@thheller thanks for your answer, I’m sorry I forgot to say that my environment is node.js v12.2.0

so you are targeting node? not the browser?

@thheller yes, and I must say that wrapping not calling directly the problematic function, but calling another async function that calls the problematic one, solved the problem

I can share part of the code if you wish

I'm asking because for node you can turn off the polyfill rewriting completely

so that problem would solve itself

not now I’m at work but if it smells like a bug I can report

@thheller oh ok, I’ll check how to do that then

just set :compiler-options {:output-feature-set :es8} or :es2018

trying right nonw

@thheller you are awesome

@thheller that was the problem! Thanks, and sorry for my incompetence in Javascript land

Is there a way to pass -Sdeps when using :deps true?

no, but you can bypass the shadow-cljs command if you need to

shadow-cljs compile app is the same as clj -m shadow.cljs.devtools.cli compile app

so clj -Sdeps ... -m shadow.... works

That’s awesome, thanks!

Can anyone tell me how to get a single bundle in development? We're currently seeing 6170 files loaded, and Chrome is choking on the last couple thousand with net::ERR_INSUFFICIENT_RESOURCES. Developing a project with material-ui.

:compiler-options {:optimizations :advanced} is doing the trick for release, but seems to have no effect on dev.

I am trying to run tests based on unit, integration, or acceptance tests. currently the namespaces look something like this

blah.bleh.integration.core-test

blah.bleh.unit.core-test

Update to my above question, :loader-mode :eval seems to have done the trick, as per: https://clojureverse.org/t/any-chance-we-could-reduce-the-bundle-size-in-development/3690/2

@satwood how do you get to 6k files? that seems like a lot 😛

FWIW this is the original :loader-mode article https://clojureverse.org/t/improving-initial-load-time-for-browser-builds-during-development/2518

@thheller Yes, it is a lot! 😆 This is how:

(:require [reagent.core :as r :refer [atom]]
           ["@material-ui/core" :as mui]
           ["@material-ui/core/styles" :refer [createMuiTheme]]
           ["@material-ui/core/colors" :as mui-colors]
           ["@material-ui/styles" :as mui-styles]
           ["@material-ui/icons" :as mui-icons]
           ["@material-ui/system" :as mui-system])

Thank you for the link to the original article! 🙌

yeah you definitely should try to reduce it to the things you actually use

otherwise your build is going to be gigantic

think it's possible to connect to a shadow-cljs repl with npm-module target on react-native platform?

sure, its what the :react-native target does

so npm-module is unneccecary?

depends. is everything CLJS or do you have existing JS and want to include some CLJS?

I'm testing Haul, so I need webpack compatability

hmm so you have a manual index.js or so?

thats used as the haul entrypoint?

yes I have index.js

that's webpack's entry, and some hmr patches

in the index.js you require("./foo/your.app")?

yes

ok in the file you can add something like if (process.env.NODE_ENV == "development") { require("./foo/shadow.cljs.devtools.client.react-native"); }

and in your build config set :runtime :react-native

ah ! I see it now, I did set the :react-native runtime

but now finally see that devtool file, only saw env, hud and browser

:npm-module just doesn't have clearly defined entries so it can't add :preloads

preloads still cause the code to be compiled

you just have to load it yourself

yes, looks like an easy workaround to me

you can try using the :react-native target btw

that takes care of all of this and should be loadable by haul

yes, if I can drop the hmr for shadow's reload, it would make sense

(it uses :npm-module in development)

which I should

I don't know what special hooks haul requires

but the react-native target is basically just an :npm-module build with a generated index.js

yes that sounds about the same with haul

so you can either use that index.js directly

or create a dedicated index.js for haul and require("./foo/index.js") from there

I'll try that now, requireing that devtool doesn't make shadow detect an environment, but that could be my side...

not sure what you mean by that

nevermind

shadow.user> (shadow.cljs.devtools.api/nrepl-select :app)
To quit, type: :cljs/quit
[:selected :app]
cljs.user> :a
REPL command timed out.
cljs.user> :a
REPL command timed out.

that might be for a variety of reasons

check the react native log

react-native log-ios or whatever that command was called

REPL should be working normally but I have no clue what you are doing to the code 😉

2019-05-22 20:35:35.535 10517-11493/com.hlolli W/unknown:ReactNative: Calling JS function after bridge has been destroyed: RCTDeviceEventEmitter.emit(["websocketMessage",{"data":"{:type :repl/invoke, :name \"<eval>\", :js \"new cljs.core.Keyword(null,\\\"a\\\",\\\"a\\\",-2123407586)\", :source \":a\", :source-map-json \"{\\\"version\\\":3,\\n \\\"file\\\":\\\"<eval>\\\",\\n \\\"sources\\\":[\\\"<eval>\\\"],\\n \\\"lineCount\\\":1,\\n \\\"mappings\\\":\\\"\\\",\\n \\\"names\\\":[],\\n \\\"sourcesContent\\\":[\\\":a\\\"]}\\n\", :warnings [], :id 2}","type":"text","id":2}])

absolutely no clue what that means 😛

ok at least there's a clue, Sherlock Holmes mode on

just a restart and now it works

it happens tough after every hot module reload, then the context which shadow is connected to is destroyed and new one is made

could I have the HMR reload some js file to sync it? like that devtools file?

by HMR you mean something haul does? because you should absolutely disable anything reloading related that haul does

no that's an opt-in

I can turn it off

I'll do that now 🙂

giving up on Haul. Better than Metro, but only by a margin. Better to use their server code and push shadow-cljs code directly from a bundle into a emulator/device. Not sure how much work that would be.