Not saying it isn’t possibly a hard problem. What if I only use L (implicitly) from one of my modules, and the dep graph for splitting decides to place it in that module because it is the only place it is used?

well, actually, I’m still OK. Because then the module info would show it in that module, and that module writer would properly call set-loaded! when it was loaded.

The error is also a bit misleading, because there are chained assertions. The call to loaded? here https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/loader.cljs#L66 is actually what is throwing the error (because loader is nil).

the error message on line 65 is the same text as that of line 50…so it is easy to get a little confused about which thing is broken.

OK. I have company that I’m ignoring. I’ll check in later tonight if I can.

Getting an error on my Windows 10 computer trying out https://ajpierce.github.io/posts/react-figwheel-npm-2/

Stacktrace java.lang.IllegalArgumentException: c:\dev\splort\node_modules\react-dom\index.js is not a relative path at http://clojure.java.io$as_relative_path.invokeStatic (io.clj:414) http://clojure.java.io$file.invokeStatic (io.clj:426) http://clojure.java.io$file.invoke (io.clj:418) cljs.closure$write_javascript.invokeStatic (closure.clj:1698) cljs.closure$write_javascript.invoke (closure.clj:1691) cljs.closure$process_js_modules$fn__15415.invoke (closure.clj:2348)

Hi, I've wrote a this app: https://calm-wildwood-56255.herokuapp.com/#/chart , using CSS transitions. But those transitions does not work correctly in some of the components. In my app, only the components who are moving upwards works well, those who are moving downwards moves instantly without animation. (I want them both moves with animation.) CSS is here:

div.canvas {
    position: absolute;
    top: 90px;
    left: 60px;
    width: 640px;
    height: 480px;
    border: 1px solid #999;
    background: white;

}

div.canvas-rect {
    position: relative;
    margin-left: 20px;
    margin-top: 10px;
    height: 20px;
    background: green;

    transition: all 1s linear;
    -moz-transition: all 1s linear; /* Firefox 4 */
    -webkit-transition: all 1s linear; /* Safari 和 Chrome */
    -o-transition: all 1s linear; /* Opera */

}

(defn rank-rects []
  (let [rank (rf/subscribe [:rank])]
    [:div.canvas-inner
     (doall (for [i    (range (count @rank))
                  :let [r (get @rank i)]]
              ^{:key r}
              [:div.canvas-rect
               {:style {:width (str (* 20 (inc r)) "px")
                        :top   (str (* i 30) "px")}}
               ]))]))

(defonce ranks (repeatedly 100 (partial shuffle (range 5))))

and every second, I set the db/rank to

(nth db/ranks (mod (- time db/init-time) 100))

@cmal CSS transitions work only when updating existing elements, not when creating them from scratch. It looks to me, that you don’t have stable keys for .canvas-rect list of elements, so React might re-render them from scratch, because there is no good mapping between existing elements in the DOM and elements you want to render. Just a wild guess

Anyways, you should be able to debug this in Chrome DevTools. This should be unrelated to ClojureScript.

Yes, but why is the key not stable, I set them to 05 and they are always 05

try to sort the items by rank in the for form

so that you feed them into react in the same order every time, 0…4

ok! Thanks for that.

Sorry @darwin, it seems the same problem: https://calm-wildwood-56255.herokuapp.com/#/chart

(defn dynamic-rank [time]
  (fn []
    [:div.canvas-inner
     (doall
      (let [rank (shuffle (range 5))]
        (for [r    rank
              :let [i (.indexOf rank r)]]
          ^{:key r}
          [:div.canvas-rect
           {:style {:width (str (* 20 (inc r)) "px")
                    :top   (str (* i 30) "px")}}
           ])))]))

@cmal: I don’t see keys on those divs

if you open in in the devtools and observe changes, you must see that the divs are not being re-created, just updated in-place

sorry , the build process has not finished

@darwin how to judge one element is being updated or created? the yellow color?

the build is finished now.

https://calm-wildwood-56255.herokuapp.com/#/chart

devtools highlights DOM changes in the Elements panel, either it highlights only changed attrs in purple or element tag in purple (that means the whole element was re-created)

the new version still doesn’t have keys

I see the key in react devtools, but not in chrome devtools

but I’m sorry, I’m not going to follow with you on this, I’m not very familiar with react

Thanks a lot..

how do integrate email in my cljs project

@tony.kay try master when you can, I reverted the loader validation stuff - I was on the fence about that anyway

@dnolen Hm. That doesn’t give me an assertion error, but the module loading is failing. I’m not sure why. It pulls the js file for the module. Possible an exception is getting thrown from within my namespace before set-loaded! is reached? I also see a lot more network traffic on the load than I did before.

@tony.kay possible, you can break on caught exceptions

@tony.kay remember set-loaded! is mandatory now

yeah, it is there.

if you’re not calling it you’re going to load stuff that’s already loaded

I’m calling it for the entry point on application start, and at the bottom of the loaded module.

It works fine if I pin the library ns into the entry point module

well, it did last night. I have not tried that on this version, cause I thought you were indicating it would not be necessary

I said no such thing

you were talking about too many different things

but now getting to what you are saying

is this namespace an “orphan”?

an orphan in the sense that I would prefer not to pin it to a module? Yes

it is “library code”

but is it even in the dependency graph?

yes, it is required in both namespaces from both modules

then I don’t see the problem

or how it’s related to what you are seeing

(yet)

I just pinned it, and it works again

when I say “orphan” I mean true orphan, unreachable

no, def not unreachable

so just need to understand what you are trying to do here, I do not

this ns is going to end up in base for sure

https://github.com/fulcrologic/fulcro/blob/develop/src/demos/recipes/dynamic_ui_main.cljs

the code is very short

the fulcro.client.routing ns is the ns in question

(that is the code for the module to load)

right but this is all a distraction for me

ok, np

since if I can understand what’s going on the other stuff doesn’t really matter

yep

so this ns ends up in base and it calls load - but it fails to load

given that it calls load after someone called set-loaded!, base is definitely already marked as loaded

so I don’t really see what could be going wrong

so, when I pin it, I only see the load of the module. When I don’t, it triggers a bunch of loads

is that expected?

no

unless something I said isn’t true and you aren’t communicating that

my lines above are my hypothesis and conclusion

it didn’t seem right to me either, but I am doing the things I said. I can check that the common ns is in base

in the js

(using optimizations none)

what triggers the load?

the load is triggered by the ns that is not pinned.

but “when”

how?

on user click of a route

so user event well after app load

ok so now I have some advice

in a REPL check your assumptions

(cljs.loader/loaded? :cljs-base)

before you click around

k

going to have to restart…give me a min. I was manually compiling to get other variables out of the way. Don’t have a repl

or you can print it somewhere

it should be true

(you do need to print it after the final statement of your entry point)

yeah, just a sec. The project was configured for figwheel, but I removed it to prevent side-effects from that. Adding REPL support via cljs

ok. true

so then confirm that was is loading makes some sense

it should be stuff that isn’t already in base

it should be obvious from quick eyeballing, loads will happen roughly in dep order

I can verify from browser console that the common lib ns is there

I’m talking about the triggered load - does it make sense

it does not, really. It is loading stuff that would have needed to be there for it to get where it already was

or at least getting the events from BulkLoader

hold on…

that’s odd. It didn’t fail this time…well, at least not in the same way

ok, but I’m still concerned about stuff loading that was already loaded

haven’t seen anything like that nor how to reproduce it - so I would think something else is still wrong

yeah, something is strange. It is loading now, and loaded? reports true for the module. But the callback didn’t seem to fire, either, and there are all the extra loads.

possibly those are all different issues

callback didn’t fire means loading failed

if loading fails, then there are retries

yeah, it was retrying earlier…but now it reports success. The callback may have fired and I’m just not seeing what I expect

but it works with the ns pinned, so the code should be right

[111.927s] [goog.net.BulkLoader] All uris loaded.
console.js:203  [111.928s] [goog.module.ModuleLoader] Code loaded for module(s): main
console.js:203  [111.929s] [goog.module.ModuleLoader] evaluateCode ids:main
console.js:203  [112.032s] [goog.module.ModuleManager] Module loaded: cljs_base
console.js:203  [112.034s] [goog.module.ModuleManager] Module loaded: main

This is the start of the messages when triggering load for the module:

[111.787s] [goog.module.ModuleManager] Registering callback for module: main
console.js:203  [111.788s] [goog.module.ModuleManager] Initiating module load: main
console.js:203  [111.789s] [goog.module.ModuleManager] Loading module(s): main
console.js:203  [111.789s] [goog.module.ModuleLoader] downloadModules ids:main uris:js/demos/goog/json/hybrid.js,js/demos/goog/net/xmlhttpfactory.js,js/demos/goog/module/moduleinfo.js,js/demos/goog/html/legacyconversions.js,js/demos/goog/useragent/product.js,js/demos/goog/module/abstractmoduleloader.js,js/demos/goog/structs/simplepool.js,js/demos/goog/net/wrapperxmlhttpfactory.js,js/demos/goog/net/eventtype.js,js/demos/goog/module/module.js,js/demos/goog/module/moduleloader.js,js/demos/goog/module/basemodule.js,js/demos/goog/net/xhrlike.js,js/demos/goog/net/bulkloaderhelper.js,js/demos/goog/module/moduleloadcallback.js,js/demos/goog/net/bulkloader.js,js/demos/goog/net/errorcode.js,js/demos/goog/net/httpstatus.js,js/demos/src/main/yahoo/intl-messageformat-with-locales.js,js/demos/goog/debug/tracer.js,js/demos/om/dom.js,js/demos/clojure/walk.js,js/demos/cljs/spec/gen/alpha.js,js/demos/cljs/spec/alpha.js,js/demos/fulcro/client/util.js,js/demos/fulcro/i18n.js,js/demos/fulcro/client/mutations.js,js/demos/fulcro/client/impl/om_plumbing.js,js/demos/fulcro/client/impl/data_fetch.js,js/demos/fulcro/client/network.js,js/demos/fulcro/client/impl/application.js,js/demos/fulcro/client/core.js,js/demos/cljs/loader.js,js/demos/fulcro/client/routing.js,js/demos/recipes/dynamic_ui_main.js
console.js:203  [111.790s] [goog.net.BulkLoader] Starting load of code with 35 uris.

you keep going back to pinning the ns fixing the issue

but that isn’t telling us anything yet really

it’s telling us that the ns itself doesn’t have syntax errors that are killing eval 🙂

yeah ok, but that’s about it 🙂

@tony.kay yeah I think we should understand why stuff is loading multiple times when you don’t pin

Are there documented differences between js-this and this-as behaviour under advanced compilation? I am switching a bunch of uses of aget to goog.object/get and found cases where (gobj/get (js-this) "someProperty") returns nil, while (aget (js-this) "someProperty") and (this-as this (gobj/get this "someProperty")) both return the correct value

would it be helpful to see the diff on cljs base between the two?

@tony.kay not really

what you are describing sounds impossible to me

base is loaded, but then loads of stuff in base are triggered again

it does seem that way. The namespaces in question already have defs at the js console, at least

at least one or two that I’ve checked

@mhuebert ClojureScript compiler may introduce closures, this-as captures this and creates scope

I just rebuilt with the common lib ns pinned to the entry point module, and it only triggers a load for the one new ns.

@tony.kay so the bug must be here

somehow loads are triggered for already loaded stuff

the only way for this to happen (w/o finding some other bug) is if what you said just isn’t true

your dep graph isn’t what you said it is

and pinning creates the right one

one thing to understand is that your pages must include all module script tags

ok, answer this: is it only requires that generate the dep graph, or is something else involved?

cljs_base.js, vendor.js, my_module.js etc. in order

oh wait…the HTML needs more than just base?

absolutely

this is in the docs

I don’t have vendor stuff

oh, but it isn’t geenrated if I don’t use it, right?

vendor this just an example

yes, I have base and the entry point module.

ok

(.call (fn []
         (prn 1 (aget (js-this) "greeting"))
         (prn 2 (gobj/get (js-this) "greeting"))
         (this-as this
           (prn 3 (aget this "greeting")))
         (this-as this
           (prn 4 (gobj/get this "greeting"))))
       #js {:greeting "Hello"})

in order

I’m not using cljs_deps.js. Is that one needed to be explicit?

@tony.kay no cljs_base.js loads that for you

ok, thought so

you should eyeball your :output-to files

:compiler     {:devcards      true
                               :output-dir    "resources/public/js/demos"
                               :asset-path    "js/demos"
                               :preloads      [devtools.preload]
                               :modules       {:entry-point {:output-to "resources/public/js/demos/demos.js"
                                                             :entries   #{cards.card-ui }}
                                               :main        {:output-to "resources/public/js/demos/main-ui.js"
                                                             :entries   #{recipes.dynamic-ui-main}}}
                               :optimizations :none}}

you should also check that cljs_deps.js looks ok

@tony.kay I mean the actual files

ok

@mhuebert hrm strange, maybe some JS weirdness here?

@tony.kay the other thing is at the JS console you should look at goog.dependencies_.nameToPath

one problem I saw until I made some fixes is that goog/base.js would be loaded multiple times - that breaks everything

@mhuebert The problem seems to be related to :static-fns, not :advanced

OK, here’s some info: The diff between base and deps on the pinned vs non-pinned js files are identical. The only difference is that when I pin the common lib ns, the diff of the entry point module now includes it in a goog.require (where it didn’t before).

but deps does show the pinned file as being needed by the entry point code

@mfikes I’ll try with both. I didn’t have a :static-fns option set on that build

@mfikes ok you’re correct, with :static-fns false it works, :static-fns true it’s nil

For reference here is the JavaScript generated for each: https://gist.github.com/mfikes/da1d13186cb6f8ff38689c8791306fa3

@mfikes thanks for that gist! seems odd that it is creating a new anonymous function there

@mhuebert My initial reaction is that your 4th form is correct, and the 2nd isn’t (additionally the 2nd is using a private macro)

@dnolen So, without the explicit pin, I am getting a load of basemodule.js: [ 12.734s] [goog.net.BulkLoader] Received event “complete” for id 11 with uri js/demos/goog/module/basemodule.js

among others

[ 12.741s] [goog.net.BulkLoader] Received event “complete” for id 15 with uri js/demos/goog/net/bulkloader.js

that one also seems pretty odd

and module, moduleloader,e tc.

right that’s what I was saying

this should be impossible

already loaded

not sure what you want me to look at in nameToPath…it has a lot of stuff. I take it this is just the way it knows a module name’s path

looks ok to me

@tony.kay everything should be there is all

also examine (.-moduleInfoMap_ cljs.loader/*module-manager*)

it has js objects for the three (base, entry point, and module to load)

(I’ve loaded at this pt)

yes but do the contents make sense?

each entry is a module with uris_

but URIs in that is wrong

I think

Yeah, the module info for the module to load has all that extra crap in it

@mfikes yeah, the generated code for the 2nd looks right. it seems strange that the :static-fns option would wrap a call to gobj/get in an anonymous fn

I’m calling it :main…that isn’t the issue I hope (name collision?)

hrm it shouldn’t matter but try

just a sec…that’s a bit of a refactor

@tony.kay what you are saying though it sounds like you have a module graph with dupes

:main just doesn’t sound important to me - I would drop that for now

@mhuebert My guess, is that, since you used (js-this) you are referring to something in a larger scope, forcing it to essentially treat it like a let binding. Just like the code you get for

(let [k "hello"]
  (gobj/get #js {:greeting "hello"} k))

(function (){var k = "hello";
return goog.object.get(({"greeting": "hello"}),k);
})()

Perhaps the aget avoids the issue given that it itself is a macro. Dunno (haven’t looked into it deeply)

Yes, I can verify that things appear in cljs_base also appear in the module to load. ok, why would I have dupes?

@tony.kay and you don’t have circular deps?

shouldn’t have. Wouldn’t the compiler puke on that?

not necessarily under :none

but that’s def the bug

duped entries

I just eyeballed it…for the three files involved, I don’t. But there are a lot of files in the project.

a second load of critical nses is guaranteed to break stuff

if I crank up optimizations will it detect circs?

it should yes, are you trying to load :main from :entry-point?

no, :main gets loaded from the library ns

what you’re saying doesn’t make sense

that saddens me 😕

are you saying it gets loaded via user interaction, yes or no?

we just need to be clear w/ our language here 🙂

yes. The user interaction happens on entry point, but entry point runs a mutation that triggers code in a diff ns that does the load

so :main gets loaded from :entry-point effectively

that’s all that matters

yes

just want to be clear because ns used to matter

and do both :main and :entry-point dupe :cljs-base ?

I tried simple optimizations. No warnings….but is broken worse.

(sounds like a bad dep graph to me, but withholding that conclusion for now)

There has to be something going on in my project that just isn’t right, I think

let me make sure something stupid like tools ns refresh isn’t getting hit during compile. I’ve had problems there before.

Hm. Nope. I cleared up the source path to make sure. Still same problem.

@tony.kay if you use :verbose with higher optimization setting you will see output info about :modules and where entries are assigned

oh, ok

I definitely see dupes between base and the module that is to be loaded

I don’t even understand how this can be remotely right

cljs.loader is only listed in the module to be loaded

as is goog.module.ModuleLoader

but when I pin the library ns to the entry point, it all clears up and looks fine…

Building module :main
  adding entry (recipes.dynamic-ui-main)
  module :main depends on :cljs-base

is exactly what I’d expect. But without pinning the library ns to the entry point, I get a bunch of stuff that makes no sense

NOTE: the lib ns ends up listed in the module to load if it isn’t pinned

but that ns is used by the entry point code

and it is only listed in the “wrong place” if it isn’t pinned.

(as in it isn’t a dupe)

so none of the things you are saying make sense and we have tests for that 🙂

if a ns is shared, it is automatically lifted to the deepest parent module

So I guess it must be something in my project…but I cannot guess what

Let me pull this out of devcards. Possibly that is confusing things

@tony.kay hold on

that may have fixed it

yeah, I think it is working now.

huh

not sure why that fixed it. Recompiling to make sure

verified. works now

so maybe devcards has a problematic dep graph?

possibly? That sucked 😛

also you wouldn’t see this under :optimizations since you probably have a different build sans devcards

I was jsut editing the build

same build

what did you change, just dropped devcards?

yeah, I moved the app out of a card and mounted directly on DOM. But that also changed by dep graph

cause I changed the entry point from the devcards UI to just my main code

Does this ring any bells?

Uncaught TypeError: Cannot read property 'isValidElement' of undefined
    at Object.r.23.112 (cljs_base.js:sourcemap:12)
    at o (cljs_base.js:sourcemap:12)
    at cljs_base.js:sourcemap:12
    at Object.r.38.112 (cljs_base.js:sourcemap:13)
    at o (cljs_base.js:sourcemap:12)
    at cljs_base.js:sourcemap:12
    at Object.r.31.10 (cljs_base.js:sourcemap:13)
    at o (cljs_base.js:sourcemap:12)
    at cljs_base.js:sourcemap:12
    at Object.r.47.1 (cljs_base.js:sourcemap:14)

cause that’s what I get (still) with :simple optimizations

though the module output list is correct

doesn’t mean anything to me

k

So, not a very good result overall 😕 Seems there are ways of making it lose its mind that remain a bit of a mystery

unfortunately what you’re doing sounds pretty dense wrt. moving parts

I know. sorry

testing :modules with random tooling is not practical

however there is a way for me to repro

all I need is your :modules which I have above

and all inputs

and then I can run the module graph code on that to see how it gets messed up

one second

well, but it only messes up in the presense of the tool stack

tool stack is not relevant

you got an impossible module graph

if we can detect that then we can at least maybe figure out blame

well, but something in the tool stack is what has the trigger to it

sure but I’m just not concerned about that

good blame would be enough and then fixes can start there

@tony.kay I added :debug-inputs to master

this will dump all compiler inputs, please email me the result as an EDN file

then I can see how you ended up with a bad module graph given your :modules

ah, ok, I see. I was thinking reproducible case and you have an alt route. Got it.

yes

@tony.kay gotta step away for a bit, but will be back online later to look at this issue

where is the file?

what file?

the EDN it generates

it doesn’t generate anything

copy and paste it and email me 🙂

oh, ok

it’s just prints to standard out

k

https://github.com/clojure/clojurescript/commit/190f3fa6bcad8f78edba2d4f509f665902c88e0f

bbiab

@mfikes so the act of calling (js-this) ends up generating a closure around its parent form which has a new this context

(js-this) simply macroexpands into (js* "this")

right, I mean what the compiler is doing in response to that

OK. I haven’t delved into the compiler behavior

so generally, if we need to use this inside a function, we should wrap the interior of the function with (this-as <some-sym>) and use <some-sym>, because at any other point inside the function, the compiler may create closures which change what this points to, and these closures aren’t represented lexically, nor are they predictable across different compile options

intuitively I would expect the compiler to munge the arg to this-as, even if it was named this in my code

@noisesmith yeah in the example that mfikes made (https://gist.github.com/mfikes/da1d13186cb6f8ff38689c8791306fa3) we see the compiler generating code like this$ = this and this_22 = this

oh, cool

You can get functions being generated for let forms. What’s odd in this case is there is no let form, but perhaps it is the same in the end: perhaps the compiler is generating a closure in order to access it. It is an interesting case.

Also, @mhuebert, it isn’t clear to me that js-this is meant for use in application code (it is marked as private)

@mfikes ah I didn’t notice that

it would make sense then that the behaviour can be unpredictable

Yeah, that’s consistent with it lacking a docstring, etc

@dnolen So, I can verify that with a very bare-bones example that module loading works as expected now. Both with none and advanced optimizations.

https://github.com/awkay/dynamic-play

Next, in a more complex project, it works fine with no optimizations. However, all other optimization levels in my project seem broken. Won’t even start. Without modules, the program works fine (including all optimization levels). Not sure how to narrow that down. It seems to be React-related in at least a few of the levels (e.g. functions get renamed erratically or removed when they shouldn’t).

That repo has three branches of interest: master is the minimum example, which works fine. The other two are minimal examples that leverage Om Next with Fulcro. The one without modules works for all opt levels. The one with modules works, but only for optimization none. They use a simple Python web server, and a shell script for build.

(run.sh and build.sh)

Hm. it is possible I did something wrong with respect to my i18n code…I use a raw js file and I didn’t configure it as a foreign lib

well, I have a deps.cljs file for it, so actually, I think I did

Hey y'all. I've been scratching my head for a few hours now trying to figure out an issue I'm having with compiling my project in development (`:optimizations :none`). I get an error that doesn't point to a line, just the file:

----  Could not Compile  /Users/lambdahands/<truncated>/db.cljs   ----

  failed compiling file:/Users/lambdahands/<truncated>/db.cljs 

----  Compiler Error : Please see /Users/lambdahands/<truncated>/db.cljs  ----

Also, I did recently upgrade to 1.9.854 - this file hasn't changed in our codebase since April or so

(on a side note I upgraded our entire application to the Clojure 1.9 alpha in a debugging hail mary, and it was super painless! 😄)

Aha! This is a classic "post your problem to Slack and the find the line that's causing it five minutes later" - so the following compiles:

#(re-matches #"[email protected]+\..+" %)

(s/def ::email #(re-matches #"[email protected]+\..+" %))

@lambdahands I can't repro:

$ java -cp ~/Downloads/cljs.jar:src clojure.main -m cljs.repl.node
ClojureScript Node.js REPL server listening on 50587
To quit, type: :cljs/quit
cljs.user=> *clojurescript-version*
"1.9.854"
cljs.user=> (require 'wont-compile)
WARNING: wont-compile is a single segment namespace at line 1 /Users/mfikes/Desktop/src/wont_compile.cljs
nil
cljs.user=> (dir wont-compile)
accounts-form
default-state
form-specs
users-form
nil

cljs.user=> (require '[clojure.spec.alpha :as s])
nil
cljs.user=> (s/def ::email #(re-matches #"[email protected]+\..+" %))
:cljs.user/email
cljs.user=> (s/valid? ::email "")
true

Hmm, interesting - I wonder if there's a dependency causing this?

What error do you get when evaluating (s/def ::email #(re-matches #"[email protected]+\..+" %))?

I actually don't get an error unless I uncomment that line in my project file and run through Figwheel - plank seems to accept my file OK

But the project compilation fails with this:

----  Could not Compile  /Users/lambdahands/<truncated>/db.cljs   ----

  failed compiling file:/Users/lambdahands/<truncated>/db.cljs 

----  Compiler Error : Please see /Users/lambdahands/<truncated>/db.cljs  ----

If you have a REPL, perhaps you can try (require 'wont-compile :reload) to see if you get any error reported back that way

Hrm, just tried and I get the same error in my REPL

Do a (pst), to see if you get more info

Even stranger, I can compile that code running in the browser REPL

I get nil after a (pst)

If you evaluate a require form, I wouldn't expect Figwheel to be involved (presuming Figwheel is the thing indicating the compiler errors you pasted above)

That's a good point - maybe I should investigate in #lein-figwheel ?

Perhaps. But require is simply a macro that expands to an ns* special form.

There ain't much Figwheel can do to break that in any way 🙂

Unless... I wonder if you have require as a REPL special?

Ah, I see - a REPL special?

Do a (doc require) to see if it is a macro

Yep, it returns a macro

Yeah, require used to be a REPL special—a special form implemented in the REPL

I have a feeling this could have something to do with some code on my classpath, but even after wiping it clean I still get the error

Oh, interesting

Well, perhaps check to see what is in db.cljs, since it seems to be complaining about that namespace 🙂

Is there any chance that the def macro in spec thinks my regex is a Java regex?

Yes... the reader will first read the regex as a Java regex

It has to be temporarily read in as a Java value, and then later the JavaScript equivalent is emitted

(This differs from self-hosted, where the reader reads regex's in as JavaScript regexs.)

At a certain point recently ClojureScript started using tools.reader so you may be on to something

I'll see if I can find a way to reproduce then!

@lambdahands If it really turns out to be an issue with it temporarily being read in as a Java regex, I suppose you could work around it by having the reader only read symbols and strings via (js/RegExp. "[email protected]+\\..+")