Fork me on GitHub
#shadow-cljs
<
2019-03-05
>
flyboarder04:03:46

boot-shadow has been updated to use shadow-cljs 2.8.14

flyboarder04:03:01

@thheller smoothest update to the boot task yet, shadow is great!

👍 16
chrisetheridge12:03:13

ignoring obvious security holes, would it be possible to run a shadow-cljs build server on an AWS instance, and connect to the cljs-repl that is exposed? such that you can hot load CLJS code from a remote repl

thheller14:03:01

@biscuitpants sure but lots of the assumptions build into the system is that files are loaded locally from disk

thheller14:03:56

so loading them purely over the REPL may not work properly

chrisetheridge15:03:45

hmm okay, and if we had all the source on disk too? so we are only compiling new code into an existing project

chrisetheridge15:03:54

so process would be: git checkout develop of our project -> start shadow build -> connect via remote repl and switch to cljs and compile

chrisetheridge15:03:17

to test i guess its just a matter of running shadow and opening the port it listens on, eh?

mhuebert18:03:29

Hmm, running into a weird bug with Maria (trying to get it using latest dependencies). the first time I compile/watch, it works. after I make a change and recompile, on reload I get a whole pile of Namespace "goog.debug.Error" already declared. errors from goog.provide. I keep getting these errors even after I refresh the browser. Killing the shadow process and compiling from scratch, then it works again.

mhuebert18:03:02

working on a minimal repro

mhuebert19:03:57

i’ve got it to happen twice in an extremely minimal project, but not in any predictable way

mhuebert19:03:29

it somehow breaks the state, this time I was able to fix by going into the repl and manually restarting the :browser build

mhuebert19:03:17

well, I can semi-reliably reproduce it in Maria by starting a watch, going into a namespace and hitting spacebar + return a couple of times, then reloading the page. it’s usually (not always) broken after one or two compile cycles. I can unbreak it via (shadow/stop-worker :live) and then (shadow/watch :live). it will load successfully, then break again soon after a bit of editing. i don’t have to do anything with the :bootstrap build.

thheller20:03:14

hmm weird. that is the error you'd get when loading things that are already loaded

thheller20:03:48

can I run maria locally? without setting up a bunch of stuff? 😛

mhuebert20:03:22

With -A:release yes

mhuebert20:03:02

shadow-cljs watch live trusted bootstrap with however you add the -A:release to that

thheller20:03:59

hmm npm install fails with a gigantic wall of text

thheller20:03:46

> [email protected] install /mnt/c/Users/thheller/code/oss/maria/editor/node_modules/node-sass
> node scripts/install.js

Downloading binary from 
Cannot download "":

HTTP error 404 Not Found

thheller20:03:24

+ another 1000 lines or so since it seems to attempt to compile node-sass

thheller20:03:56

$ shadow-cljs -A:release watch live trusted bootstrap
shadow-cljs - config: /mnt/c/Users/thheller/code/oss/maria/editor/shadow-cljs.edn  cli version: 2.8.14  node: v10.13.0
shadow-cljs - starting via "clojure"
Downloading: appliedscience/js-interop/0.1.11/js-interop-0.1.11.pom from 
Error building classpath. Manifest type not detected when finding deps for lark/tools in coordinate {:git/url "", :sha "113b9f6f8d8ff7a3c35864fb5f50c20be61c729e", :deps/root "tools"}

mhuebert21:03:28

let me figure this out, haven’t seen it before but I see it is happening on circleci too

thheller21:03:45

I just cloned the other repos then it at least seems to start

thheller21:03:26

ok seems to be running. looks a bit weird because css is missing

thheller21:03:29

what do I do now?

mhuebert21:03:46

i am getting rid of the webpack thing as I wanted to deprecate that stage anyway. but I don’t know why you got the lark/tools error, that part works for me

thheller21:03:24

------ WARNING #1 - :undeclared-var --------------------------------------------
 File: /mnt/c/Users/thheller/code/oss/maria/editor/src/maria/live/source_lookups.cljs:117:40
--------------------------------------------------------------------------------
 114 | (defn var-source
 115 |   "Look up the source code corresponding to a var's metadata"
 116 |   [{{meta-file :file :as meta} :meta file :file name :name :as the-var} cb]
 117 |   (if-let [logged-source (some-> (get @live-eval/evaluated-sources-by-filename meta-file)
----------------------------------------------^---------------------------------
 Use of undeclared Var lark.eval/evaluated-sources-by-filename
--------------------------------------------------------------------------------
 118 |                                  (source-of-top-level-form the-var))]
 119 |     (cb {:value logged-source})
 120 |
 121 |     (if-let [source-name (some-> (namespace name)
--------------------------------------------------------------------------------
`

mhuebert21:03:20

oh, i just renamed that var locally - pushed the new commit of lark/tools, 05bc43a10e8a72ba552cc87fd2794eb9db6f06c7

mhuebert21:03:38

i am just working on getting this building in circleci again

thheller21:03:36

oh I think I found the problem without having actually reproduced it

thheller21:03:56

the live+trusted builds use the same :output-dir

thheller21:03:13

that is not a good idea in dev mode and questionable in production a bit too

thheller21:03:32

each build should have its own directory

thheller21:03:45

otherwise the dev files will override each other

mhuebert21:03:20

well that would explain the weird nature of these errors

thheller21:03:34

yeah it would definitely cause weird stuff to happen

thheller21:03:19

:async-require true this isn't required anymore. it is detected at runtime.

thheller21:03:15

I'm not actually sure the shared output-dir causes these errors but it might

mhuebert21:03:22

i’ll try it now

mhuebert21:03:20

i think that was it

mhuebert21:03:07

not seeing errors any more, and different-builds-overwriting-each-other would explain everything i was seeing

mhuebert21:03:48

looking at the example i had set up, i had two different output-dirs there

mhuebert21:03:01

{:deps true
 :dev-http {8000 "public"}
 :builds {:browser {:target :browser
                    :modules {:app {:entries [shadow-ex.core]}}
                    :output-dir "public/compiled"
                    :asset-path "/compiled"}
          :bootstrap {:target :bootstrap
                      :output-dir "public/js/compiled/bootstrap"
                      :entries [shadow-ex.core]
                      :exclude [cljs.js]}}}

mhuebert21:03:00

but, i am not seeing any problems in maria now

👍 5
tomc20:03:27

I'm trying to convert a figwheel-based cljs project to shadow-cljs so that I can compare the dev experience. I have a javascript library (not from npm) under :foreign-libs in my figwheel config. How do I translate that to shadow-cljs?

thheller20:03:23

what kind of javascript lib?

thheller20:03:35

commonjs? es6?

tomc20:03:18

neither, it just defines a function in the global scope

thheller20:03:58

does it have a goog.provide?

thheller20:03:01

basically you can skip all the foreign-lib stuff and just require the file directly

tomc20:03:12

Looks like this is exactly what I need. Thank you.

tomc20:03:00

Great work on the shadow-cljs docs by the way. Nice to use a clojure project that holds the user's hand a bit.

😎 5