Fork me on GitHub
#clojurescript
<
2017-08-16
>
sam1606:08:41

Can anyone link/help me integrate google signin in clojurescript

sam1606:08:36

Can someone share a snippet in cljs if possible

bendlas12:08:58

hey, https://github.com/material-components/material-components-web uses an npm package name of @material. This produces import errors. Is there any workaround for this?

bendlas12:08:29

.. besides prepackaging it with webpack ...

dominicm12:08:17

@bendlas are you using the :npm-deps feature?

bendlas12:08:15

right now, I've reverted to using the precompiled bundle, they provide, but I'd like to import it directly

bendlas12:08:38

the unusual @material identifier seems to get in the way, @dominicm

dominicm12:08:06

@bendlas so if this were js you'd do require('@material')? 😱

bendlas12:08:07

not sure if that's a failure in clojurescript or in google closure

dominicm12:08:31

Hmm :thinking_face:

dominicm12:08:40

What does your :npm-deps look like?

bendlas12:08:59

yes, rather `require('@material/card') or something

dominicm12:08:41

@bendlas Oh, gotcha. npm-deps should be fine then. How does your cljs :require look?

bendlas12:08:57

:install-deps         true
                                    :npm-deps             {:material-components-web "0.17.0"}

bendlas12:08:59

I've tried [@material.card], ["@material.card"] as well as ["@material/card"]

bendlas12:08:17

I suspect it's a gclosure fail, since you can also require [material-components-web], then the transitive require for @material modules fails too

sundarj12:08:54

if the npm dep is material-components-web, then the only entry point is that - so it would have to be something like (:require [material-components-web :as material])

bendlas12:08:16

@sundarj exactly. That fails

bendlas12:08:41

it fails because of transitive dependencies to @material modules

sundarj12:08:48

right, gotcha

dominicm12:08:05

@bendlas did you mean ["@material/card" :as card]?

dominicm12:08:39

or maybe it's "material-components-web/@material/card" :thinking_face:

bendlas12:08:15

@dominicm I've tried the first one, nope @ second one. see https://unpkg.com/[email protected]/index.js

dominicm12:08:08

ah, looks like material-components-web actually depends on "@material" or something

dnolen12:08:18

not that it will fix your issues, but you should use the exact same name you would use in Node.js when requiring. In the case where it would not be a valid symbol or it would be munged, use string require

bendlas12:08:32

@dnolen i figured that. seems like closure is at fault. I'll try with the latest version and maybe report a bug ..

dnolen12:08:47

not necessarily, this is all brand new stuff

dnolen12:08:59

we’re doing far more with it than anyone else using Closure Compiler far as I can tell

dnolen12:08:10

and we’re pushing it faster with patches etc.

dnolen13:08:17

when you say “import errors” I’m assuming Closure says it’s couldn’t import some module

dnolen13:08:26

but all that means is that it couldn’t find it

dnolen13:08:36

and it couldn’t find it because we didn’t pass it in

bendlas13:08:18

right, I'm not quite sure about who does what about npm deps between cljs and gclosure. the transitive modules showed up in <root>/node_modules but not in <cljs-out>/node_modules

dnolen13:08:48

so those deps weren’t found by us

dnolen13:08:03

you may want to try your project with master

bendlas13:08:10

OK, so the error with cljs master is the same: 1) when requiring something like ["@material/card" :as mc], the analyzer fails with No such namespace: @material/card, could not locate _CIRCA_material_SLASH_card.cljs, _CIRCA_material_SLASH_card.cljc, or JavaScript source providing "@material/card" 2) when requiring the parent namespace [material-components-web :as mcw], it compiles but gclosure can't find the sources: `Uncaught Error: Undefined nameToPath for module$home$herwig$checkout$diagnosia_app$node_modules$$material$drawer$temporary at visitNode (base.js:1357) at visitNode (base.js:1355) at visitNode (base.js:1355) at visitNode (base.js:1355) at visitNode (base.js:1355) at Object.goog.writeScripts_ (base.js:1369) at Object.goog.require (base.js:706) at (index):15`

dominicm13:08:42

@dnolen can confirm, but I suspect cljs might not package up transitive dependencies for google closure.

dominicm13:08:23

Hmm, maybe not actually, given the failure in 2.

dnolen13:08:26

@dominicm that’s not accurate

dnolen13:08:53

we handle transitive deps

dnolen13:08:12

the reasons this might not be working are many

bendlas13:08:29

is the second dollar sign in node_modules$$material a munged @, or is that always there?

dnolen13:08:53

that’s just a Closure generated module name

dnolen13:08:54

@bendlas oh but I think I know what might be happening, we only index the top level

dnolen13:08:10

if your code is trying to require a transitive dep that isn’t going to work and we don’t support that

dnolen13:08:33

you need to express an explicit dep on anything you want to bring in

bendlas13:08:02

ok, that explains #1 right?

dnolen13:08:13

(actually I don’t know if that’s the problem here, but it’s something to check)

dnolen13:08:28

I don’t know

bendlas13:08:28

funnily: cljs_deps.js contains paths like goog.addDependency("../node_modules/@material/base/foundation.js", ['module$home$herwig$checkout$diagnosia_app$node_modules$$material$base$foundation'], []);

dnolen13:08:35

fix your deps and check 🙂

dnolen13:08:48

@bendlas well those are relative urls, but what’s there in your :output-dir?

bendlas13:08:42

@dnolen as opposed when I checked before, the output folder now contains node_modules/@material

dnolen13:08:16

then I don’t think there’s anything weird here

bendlas13:08:48

but there is stuff missing

dnolen13:08:01

that’s a different problem

bendlas13:08:03

do I need to list all that in :npm-deps?

dnolen13:08:14

that always means something didn’t get resolved

dnolen13:08:37

@bendlas if the lib you want to require is not in the dep, it’s not going to work

dnolen13:08:41

that’s the rule

bendlas13:08:14

but it is in the dep

dnolen13:08:23

then there’s something wrong 🙂

dnolen13:08:34

and I don’t have any ideas about that

dnolen13:08:55

I’m just removing the random guessing about how this is supposed to work 😉

dominicm13:08:57

Looking through the https://github.com/material-components/material-components-web package.json, I can't actually see @material/card or anything like it.

bendlas13:08:31

@dnolen so the current failure is that none of the subdirs of @material/drawer get included: https://unpkg.com/@material/[email protected]

dnolen13:08:14

@bendlas why should they get included?

bendlas13:08:56

@dnolen because in the index.js, there is are lines like: export {MDCTemporaryDrawer, MDCTemporaryDrawerFoundation} from './temporary'

dnolen13:08:01

(I’m asking what would trigger them to get included?)

dnolen13:08:28

I mean in your project

dnolen13:08:41

we don’t randomly copy everything over

dnolen13:08:46

only stuff we see that you need

bendlas13:08:56

so I do need to list all my transitive deps?

dnolen13:08:11

I’m asking a very simple question

dnolen13:08:17

what depends on drawer?

dominicm13:08:21

material-components-web does for one.

bendlas13:08:27

@dnolen the top-level index.js does: goog.addDependency("../node_modules/material-components-web/index.js", ['module$home$herwig$checkout$diagnosia_app$node_modules$material_components_web$index'], ['module$home$herwig$checkout$diagnosia_app$node_modules$$material$auto_init$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$base$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$checkbox$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$dialog$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$drawer$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$form_field$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$grid_list$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$icon_toggle$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$linear_progress$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$menu$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$radio$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$ripple$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$select$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$slider$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$snackbar$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$tabs$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$textfield$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$toolbar$index']);

bendlas13:08:03

(:require ["@material/card"]) can't even be analyzed.

bendlas13:08:01

The weird thing is, drawer depends on it's subdirs: goog.addDependency("../node_modules/@material/drawer/index.js", ['module$home$herwig$checkout$diagnosia_app$node_modules$$material$drawer$index'], ['module$home$herwig$checkout$diagnosia_app$node_modules$$material$drawer$util', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$drawer$temporary', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$drawer$persistent']);

bendlas13:08:15

but those aren't there in cljs_deps

bendlas13:08:35

so it seems that it indexes modules within the same directory, but subdirectories are ignored @dnolen

dnolen13:08:37

@bendlas https://github.com/material-components/material-components-web/tree/master/packages/mdc-card, side note, let’s paste snippets to avoid flooding the channel like that

dnolen13:08:53

I don’t see any JS at all under this package

bendlas13:08:47

yes, sorry.

dnolen13:08:57

@bendlas there’s no JS under drawer either

dnolen13:08:07

so of course there’s isn’t going to be anything

dnolen13:08:59

oops sorry missed that, was only looking at permanent

bendlas13:08:04

but yeah, many @material packages just have .scss files. I was going to figure out the appropriate babel transform later

dnolen13:08:38

@bendlas playing around with this over here

bendlas13:08:06

great! I can revisit this later, when I'm not on company time. for now, I'll just use the prepackaged version.

dnolen14:08:22

Antonió could provide some insight later when he’s on as well - I’m pretty sure someone else had tried material and they had gotten further

dnolen14:08:01

@bendlas I can repro your issue here, it just seems we’re not properly computing the node_modules inputs that must be passed through Closure in this case

daiyi14:08:52

hello \o/ is there a canonical simple cljs library people like to use for using localStorage?

dnolen14:08:38

@daiyi I would probably just look to see if Google Closure has something first

daiyi14:08:59

oh good idea, thanks!

daiyi14:08:18

(I should make a better habit of looking into goog closure)

juhoteperi14:08:10

@daiyi I think Closure lib has something, but you can also check https://github.com/alandipert/storage-atom which hides localStorage behind an atom (not sure if good idea) and takes care of encoding/decoding using Transit

bendlas14:08:11

@dnolen thanks for digging into the issue. let me know, if you could use any help with the ticket

souenzzo14:08:59

storage-atom is pretty nice. You can use with add-watch

dnolen14:08:15

@daiyi there’s a bunch of mechanisms

dnolen14:08:20

depending on what you’re doing storage-atom might also work for you - but I’m generally loathe to take on dependencies for basic stuff like this

dnolen14:08:05

the affordances often aren’t worth the trouble - but your mileage may vary - and it’s really depends on the project

dnolen14:08:19

for something serious I would not take on a dep - for fun - sure

dnolen14:08:37

@bendlas well if you’re curious I believe the issue has to be with module_deps.js

dnolen14:08:02

we have a Node.js script that compute the set of inputs we need to pass to Closure

vinai14:08:44

Hi! I need to make simple jquery callback after a component is rendered. How can I specify that function name as an extern before running lein cljsbuild once min? Grateful for any pointers.

daiyi14:08:22

I did feel like it's quite a simple task that probably doesn't need dependencies. I'll start with google closure, thank you!

dnolen14:08:52

@daiyi it’s also just nice to get familiar with Google Closure Library - it’s really a treasure trove

dnolen14:08:12

once you wrap your head around you realize there’s just so many cases where you don’t need third party JS dep

dnolen14:08:14

or a CLJS dep

daiyi14:08:54

I've noticed lots of advanced clojurescript people using it very often, so I suspect it's a power I should unlock :D I'm surprised not more javascript people use it

dnolen14:08:12

@daiyi it’s not straightforward to consume for JS people because it’s a module convention that predates modern JS and is somewhat conceptually at odds

dnolen14:08:27

everything is global, scope is managed via ubiquitous namespacing

daiyi14:08:42

ah, people don't like that anymore

dnolen14:08:47

this definitely is at odds with JS conventions

dnolen14:08:58

however it’s awesome for a Lisp like ClojureScript

dnolen14:08:01

hot-loading is trivial

dnolen14:08:42

it’s also not difficult to rewrite JS into Closure style, that’s how all this new fancy node_modules stuff works

dnolen14:08:18

@bendlas I think I see the problem export ... from JS pattern doesn’t seem to get picked up?

dnolen14:08:47

in index.js for drawer I see the util import works but not the 2 export ... from at the bottom of the file.

dnolen14:08:53

yeah it seems Closure does the right thing with export ... from statements, but those deps aren’t getting passed in as inputs

dnolen14:08:07

the issue is looking more and more like module_deps.js

bendlas14:08:55

@dnolen right, i wasn't sure whether this was bc if export .. from or because of subdirs ...

dnolen14:08:09

subdirs not an issue

dnolen14:08:20

we have scoped package resolution in module_dep.js

dnolen14:08:23

the problem is konan

dnolen14:08:41

we use that to understand import when collecting inputs, but konan doesn’t appear to support export ... from

jrychter14:08:06

Hmm. I tried to switch from ClojureScript 1.9.521 to 1.9.854 and I get:

#error {
 :cause com.google.protobuf.GeneratedMessageV3
 :via
 [{:type clojure.lang.Compiler$CompilerException
   :message java.lang.NoClassDefFoundError: com/google/protobuf/GeneratedMessageV3, compiling:(cljs/closure.clj:210:3)
   :at [clojure.lang.Compiler analyzeSeq Compiler.java 6926]}
  {:type java.lang.NoClassDefFoundError
   :message com/google/protobuf/GeneratedMessageV3
   :at [java.lang.ClassLoader defineClass1 ClassLoader.java -2]}
  {:type java.lang.ClassNotFoundException
   :message com.google.protobuf.GeneratedMessageV3
   :at [java.net.URLClassLoader$1 run URLClassLoader.java 372]}]

Does this ring a bell with anyone? I'm not sure how to even approach this.

dnolen14:08:48

@jrychter dependency issues

dnolen14:08:59

something is clashing

dnolen14:08:09

(I’m referring to JVM deps)

dnolen14:08:52

likely something is overriding a dep Closure Compiler needs

dnolen14:08:35

@bendlas yep I just repro’d the problem with konan

bendlas14:08:31

So .. @dnolen stands for Detective Nolen, right?

jrychter14:08:49

Ok, I'll try staring really hard at lein deps…

dnolen14:08:01

@jrychter no need lein deps :tree

dnolen14:08:21

it will list conflicts

jrychter14:08:30

@dnolen That's actually what I meant. And it does suggest considering "[org.clojure/clojurescript "1.9.854" :exclusions [com.google.protobuf/protobuf-java]]".

jrychter14:08:23

Which is actually not what I want

dnolen14:08:17

look at what else needs protobuf-java that isn’t ClojureScript transitive

jrychter14:08:51

I think I found it. Two packages: bouncer, which requires an older version of ClojureScript, and clj-rethinkdb, which uses protobuf-java 3.0.0-alpha-3.1 directly. I'll add an exclude to clj-rethinkdb.

jrychter15:08:22

@dnolen Yep, that did it. I'll work with clj-rethinkdb to update their protobuf-java version. Thanks for the help!

bendlas15:08:44

@dnolen I'll report to https://github.com/egoist/konan/issues, unless you're already on it ...

dnolen15:08:10

@bendlas not worth it IMO

dnolen15:08:23

would prefer to get out of Node.js dependency silliness

bendlas15:08:42

right, I'll report it anyway, even if we stop using it

bendlas15:08:53

just out of courtesy

dnolen15:08:00

makes sense

Aron15:08:21

not sure why we needed ecmascript modules in javascript, i am personally not a fan 😞 we could've had better number types or better data structures. instead we have async module load.

bendlas15:08:42

@ashnur for the same reason we need to suport .jars in Clojure. Interopability. If you don't need it, good for you.

Aron18:08:09

i think you misunderstand. when i said "we" i mean "we humans", not some vague subset of people. i don't think we put it into js because of interop, there was no import/export before. we had commonjs and it was fine. some people were exploring other stuff, that was fine too.

bendlas15:08:45

Clojure always has been a pragmatic language. A core difference to other interesting, but ultimately impractical, languages is, that Clojure never tried to hold up the river by standing in the middle and pretending it wasnt there.

bendlas15:08:36

ES6 Modules are what javascript is converging to as a module system and clojurescript's technical direction is not the place to fight that trend.

bendlas15:08:29

So I'm not sure whether you're arguing that ES6 shouldn't exist or whether cljs shouldn't support its modules, but either way, unless you have a good alternative solution for interacting with npm, i project that people are not going to listen.

Aron02:08:36

as i said, i was not talking about clojure

bendlas15:08:10

there have been many people in the community, welcoming this with teary eyes

dnolen15:08:06

yes, lack of JS modules was a huge problem

Aron18:08:05

we had commonjs way before ESM, i did not need import export. 🙂 not sure who was not fine with commonjs and why they had to put a way more complicated stuff into the language.

dnolen21:08:43

I don’t have anything good to say about commonjs, it’s not that good

Aron02:08:18

it was good enough, now there is a rip in space time because of this, because if I use browserify as i did before, i there are certain possible combinations that just simply don't work, so i can't do that. then there are the ES6 modules, but those have their own problems: https://github.com/d3/d3/issues/2733

bendlas15:08:05

Just a heads-up with cljs master, I get async.cljs?rel=1502892032791:13 Uncaught TypeError: goog.net.jsloader.load is not a function @bhauman

dnolen15:08:20

@bendlas pretty sure @tony.kay saw the same thing - Figwheel doesn’t seem to work with :modules

dnolen15:08:10

unlikely to delay a release just for Figwheel and this feature though

dnolen15:08:46

if somebody can come up with a theory why it doesn’t work I’ll take a look at - but I’m not going to do any initial research myself - this release has been delayed too long already

bendlas15:08:53

@dnolen I'm not using :modules. Neither npm ones, nor closure ones. I wasn't suggesting to delay either, but I'd love for figwheel to fix this asap. Looks like one of the removed closure namespaces to me

juhoteperi15:08:10

Does latest Cljs update Closure-library?

dnolen15:08:24

@juhoteperi it did yes, you can always downgrade it manually though

dnolen15:08:37

@bendlas oops sorry, I thought that was something to do with cljs.loader

juhoteperi15:08:01

Okay, probably Fighweel needs to start using safeLoad instead of removed load. Boot-reload has the same problem.

juhoteperi15:08:06

load has been deprecated for ages, I think, but we haven't seen deprecation warnings so there will be some broken code

juhoteperi15:08:21

Maybe because Closure only shows warnings when doing advanced build and figwheel nor boot-reload are not used in that case

anmonteiro16:08:37

@dominicm @sundarj @bendlas I'm glad David ended up finding your issue. I'll get to it soon, but will probably not be in today's release. Just a side note: it doesn't help very much coming up with theories based on random guessing for why things don't work. In fact, we do index the entire node_modules installation (we just don't descend into nested node_modules/pkg/node_modules). We do support requires of the form @foo/bar/baz and whatever form you can think of (like collapsing x/index.js to x, etc.

bendlas16:08:28

@anmonteiro thanks! I try to avoid random guesses. My first theory about the @ being the problem turned out to be false, but it was based on my not seeing the folder in the output directory (for whatever reason)

anmonteiro16:08:23

Something that I find very useful when looking at things like this is to consult the tests

anmonteiro16:08:38

And we do have a bunch of tests in CLJS for all this

bendlas16:08:59

yeah, I get that false starts like this are frustrating from a maintainer's perspective, I have been on that side as well, but there really wasn't that much random guessing involved. I'll try to do better though. Looking at tests when diagnosing is probably a good idea.

dnolen16:08:56

@bendlas in particular for :npm-deps

dnolen16:08:04

it just spreads confusion at this stage to guess 🙂

juhoteperi16:08:10

@bendlas & others I reported the jsloader problem on figwheel with details (https://github.com/bhauman/lein-figwheel/issues/594) and pushed a new snapshot of Boot-reload with the fix

bendlas16:08:48

well, yeah. I tried to be more specific than "library x doesn't work" and the guess wasn't random, but I'll try to describe the actual situation, next time @dnolen @anmonteiro

bhauman16:08:49

@juhoteperi thanks for the heads up

bbloom16:08:41

can i give multiple directories to cljs.build.api/build ?

bbloom16:08:01

or do i need to use :libs ?

juhoteperi16:08:25

@bbloom Directories that contain cljs sources? cljs.build.api/inputs

bbloom16:08:45

gotcha - will try that, thx

juhoteperi16:08:30

@bbloom But ClojureScript also looks for sources in classpath, if I recall correctly, only the directory which contains :main ns needs to be in inputs

briantrice16:08:45

de-lurking for a moment: very glad to see that all the Cool Kids are here, now that I’ve taken up a clojure/cljs job. 😄

bbloom16:08:23

hey brian - nice to see you here 🙂

briantrice16:08:57

thanks! you too 🙂

bbloom16:08:14

i haven’t been writing much cljs lately - just trying to help fix a fipp bug somebody reported

anmonteiro16:08:16

@bendlas I have no problem with “library X doesn’t work”. the problem here was guessing that could cause misinformation to newcomers or other people looking to try out this feature

anmonteiro16:08:42

anyway, I think you get my point and nothing constructive is going to come out of this

briantrice16:08:45

you know, if I had a wishlist for cljs/om, it’d be something like Rx. But I’ve been on an Rx kick for a few years now.

sundarj20:08:43

i imagine it wouldn't be too difficult to write an RxClojure-like wrapper around RxJS

briantrice01:08:32

I am tempted!

bbloom16:08:23

what do you need out of rx? i’ve found it to be a pretty painful model to work with in practice

bbloom16:08:44

i even wrote an rx-like with cljs & decided “this is a bad idea” and i know a core contributor to microsoft’s original rx 🙂

bbloom16:08:09

i bet we can find you an alternative that meets your needs 🙂

briantrice16:08:09

what made it feel wrong?

bbloom16:08:27

for servers/etc, the default is a lack of back pressure

briantrice16:08:32

yeah, that’s what I’d like to hear; what suffices that need. Om or bare react misses some things.

bbloom16:08:58

but more generally, it’s a model built on incorporating time in to sequences - which is an unnecessary complication

bbloom16:08:24

you can add trasducers to channels, which means that all transformation remains synchronous - you can handle time with other mechanisms

briantrice16:08:27

yeah, except when time matters!

bbloom16:08:42

in that case, i’ve found a queue to work much better

briantrice16:08:45

can I write a continuous abstraction over time that composes?

bbloom16:08:02

no, but then again, i’m not sure you really want to 🙂

briantrice16:08:07

maybe a state-machine composition…

bbloom16:08:25

let’s make it concrete & i can explain my thinking - do you have an example?

briantrice16:08:29

oh, man, see, that’s where people start discounting user requirements in my experience.

bbloom16:08:30

of what you’re trying to do where rx would help?

briantrice16:08:49

not right this second; still on day 8 of the new job.

bbloom16:08:06

feel free to @ me when you do, happy to help explore alternatives

briantrice16:08:19

last job was react/redux and I really needed to throttle and debounce non-UI stuff quite a lot, and use mediated/programmatic throttling.

briantrice16:08:42

for high-volume interactive data-viz where the frontend had to do a lot of the crunching.

briantrice16:08:49

PureScript was the “preferred fancy UI language” but it did not meet my needs.

bbloom16:08:33

not sure i follow - what were you debouncing? server sent events?

briantrice16:08:03

aggregations were map/reduce jobs and the UI had to perform a streaming reduce

briantrice16:08:49

redux-saga was the presumed performer for a lot of work in that area but the team was too uncomfortable with both that and Rx.

bbloom16:08:33

a streaming reduce over what?

briantrice16:08:57

each DB shard would perform its own agg and send its results.

briantrice16:08:05

or … partition, really.

briantrice16:08:00

eh, this is too much right now. I’d be happier to hear about effect types in dynamic languages, if you’re still on that @bbloom.

bbloom16:08:25

heh, sorry

bhauman20:08:59

@juhoteperi @dnolen I just pushed the fix for the jsloader deprecation

bhauman20:08:05

@juhoteperi I'm changing my fix so that it's backward compatible, the current fix is only good for CLJS >= 1.9.223

bhauman20:08:23

thats a bit narrow and will definitely cause problems for folks

juhoteperi20:08:07

@bhauman Ah, good catch, I'll copy the fix to boot-reload 🙂

bhauman21:08:48

checking to see that 1.9.908 works

bhauman21:08:58

in figwheel

bhauman22:08:57

good stuff cljs 1.9.908 works in the newly released figwheel 0.5.13

dnolen22:08:51

@tony.kay I believe this should address the Figwheel issues you saw, totally unrelated to :modules