Fork me on GitHub
#shadow-cljs
<
2018-03-24
>
lwhorton00:03:57

i’ve dug around here https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/devtools/api.clj#L81 looking for the reason that I cannot seem to get (devtools.api/watch build-id) to work, and it seems like there’s some stateful dependencies in an existing runtime?

lwhorton00:03:53

i get the issue assert failed (map? http), which if you backtrack quite a bit seems to be coming from an existing supervisor who has some http config. i’m not sure if there’s an alternative way I should be using the clj-run api or not, but this doesn’t seem to be correct 😕

thheller00:03:34

clj-run currently doesn't spin up a full server so watch doesn't work

thheller00:03:46

if you run a separate shadow-cljs server it should work

thheller00:03:19

on my way to bed. please open a ticket. there should be an option for clj-run to run a full server to enable watch

mhuebert09:03:50

This would be great. I’d like to have a script for dev which always compiles a few static assets before beginning ‘watch’, and I think clj-run would be the simplest way to set that up.

mhuebert09:03:50

This would be great. I’d like to have a script for dev which always compiles a few static assets before beginning ‘watch’, and I think clj-run would be the simplest way to set that up.

mjmeintjes09:03:12

Is there are way to use shadow-cljs and browserify together? I'm trying to require a npm module (pouchdb-adapter-memory), but when I include it in my namespace requires it throws the following error:

shadow.js.js:91 Uncaught ReferenceError: Buffer is not defined
    at Object.shadow$provide.module$node_modules$buffer_from$index (index.js:5)
    at shadow.js.jsRequire (shadow.js.js:88)

mjmeintjes09:03:08

The solution of Buffer is not defined error is to run the module through browserify, but I'm not sure how to integrate that with shadow-cljs.

thheller09:03:54

in the namespace that includes pouchdb-adapter-memory add an extra require for a (ns bugfix.buffer (:require ["buffer" :as buffer])) (js/goog.exportSymbol "Buffer" buffer)

thheller09:03:56

I could a hack to do this automatically but most packages these days behave properly and don't use a global Buffer

thheller09:03:05

sicne that only exist in node

thheller09:03:42

import bufferFrom from 'buffer-from'; // ponyfill for Node <6

thheller09:03:27

are you sure this is intended to work in the browser?

thheller09:03:31

looks pretty node specific

thheller09:03:41

if you require bugfix.buffer (or whichever ns you use for this) before the pouchdb thing it should work

thheller09:03:47

just need to make sure the global exists before using it

mjmeintjes09:03:21

Thanks, that did the trick. Where I got stuck is that I didn't think to set the global in a separate namespace - I tried setting it in the same namespace which of course didn't work. Thanks for the quick reply.

mjmeintjes09:03:50

They do state on the npm page "Designed to run in either Node or the browser".

mjmeintjes09:03:18

I've found some of the other less maintained pouch plugins have similar issues, one plugin had a requirement for Process

mjmeintjes09:03:39

Thanks for this quick reply, appreciate the help!

hlolli11:03:14

I want to give some of those cljs devtools a try again, looking at dirac there's suggested way to start their agent (assumable on nrepl server) with :init in lein

:repl-options {:init (do
                       (require 'dirac.agent)
                       (dirac.agent/boot!))}
source: https://github.com/binaryage/dirac/blob/master/docs/installation.md is there an option like that available in shadow-cljs?

thheller11:03:17

not really but you could use clj-run

thheller11:03:31

I'll probably add some hook options later today

thheller11:03:37

so that things like this become easier

hlolli11:03:18

ok, I'm also planing to look at integrating the clj cli tools into nixOs so I can use them later today. So I'll continue with the devtools quest tomorrow. Thanks thheller!

hlolli11:03:12

(lein would work I guess)

wilkerlucio19:03:32

hello, I'm trying to compile something with shadow, but I'm getting this error:

wilkerlucio19:03:23

I had a lot of code changes since the last time I compiled (was working on the clj side), and just bumped shadow as well, not sure what might caused

wilkerlucio19:03:59

I"m trying to rever t and see if I get teh same with old shadow, but you guys have seen this before?

wilkerlucio19:03:31

reverting shadow to 2.1.18 makes it generate warnings instead of breaking

thheller19:03:47

incompatible closure version

thheller19:03:21

clojurescript itself is pretty tied to a specific closure version

wilkerlucio19:03:25

is there a way to fix? when I reverted I was able to compile by fixing some macro requires, but now I bumped again and the error persists

thheller19:03:45

the error has nothing to do with macro requires

thheller19:03:07

that is just a side effect of the cljs.repl ns requiring cljs.closure

thheller19:03:20

and that is the ns that is broken

thheller19:03:39

you can (require 'cljs.closure) to verify this in a clojure REPL

thheller19:03:21

so its not the shadow-cljs version that is the problem here

thheller19:03:26

its clojurescript+closure

wilkerlucio19:03:53

ok, I think I'm starting to understand, but the cljs version is the same on both cases for me, when did the closure get updated? and it seems like this way I can't compile anything at all, the only way is to revert shadow here then?

thheller19:03:19

shadow has nothing to do with this

thheller19:03:29

it is the closure version in combination with clojurescript

wilkerlucio19:03:40

but reverting shadow here makes it work, I think I'm missing something

wilkerlucio19:03:56

I'm still on cljs 1.9.946

thheller19:03:06

remove that

thheller19:03:28

let shadow-cljs pick the clojurescript version

thheller19:03:49

or use [org.clojure/clojurescript "1.10.145"]

thheller19:03:13

previously I used a hack to provide a custom cljs.closure namespace but that had other issues

thheller19:03:59

it is kind of tricky trying to stay up to date with the closure compiler and clojurescript itself lags behind

wilkerlucio19:03:11

gotcha, just feel a little danger using those non-release versions, seems people are getting bitten by new things still, like the new map stuff

thheller19:03:16

should work better once the official clojurescript 1.10 comes out

thheller19:03:27

new hash stuff?

wilkerlucio19:03:41

sorry, map* stuff (new map keys been entity)

wilkerlucio19:03:17

but for my current project it's work, I'm just wondering for people relying on it for real prod stuff

wilkerlucio19:03:32

I guess they should lock the shadow-cljs if they have problems with new cljs things

thheller19:03:01

well you want to fix those things anyways. clojurescript isn't going to change how MapEntry works

thheller19:03:16

so if you relied on broken behaviour you have to change it or forever stay on 1.9

thheller19:03:53

for me 1.10 has been stable. the only non-stable part is all the new cljs.main stuff but we don't use any of that anyways so it doesn't matter

wilkerlucio19:03:59

yeah, I agree, but sometimes you depend on a library that you don't have much control, and it might take a while to fix, and on those cases you get locked, unless you decide to fork... tradeoffs

wilkerlucio19:03:17

at least people seem to be fixing it fast 🙂

thheller19:03:37

do you know of particular libs that break?

wilkerlucio19:03:47

specter was broken, but was fixed already

wilkerlucio19:03:16

and now it's working here, thanks for the explanations

👍 4
wilkerlucio20:03:05

ok, I think I'm hitting another hookie mistake, but on runtime I'm getting these: https://www.dropbox.com/s/vx09tnx0cu4si7c/Screenshot%202018-03-24%2017.36.45.png?dl=0

wilkerlucio20:03:36

I was using React 16 with project already before, did something changed about loading the cljsjs deps?

thheller20:03:33

shadow.process is the cause. don't know why that wouldn't exist though. maybe cache issue?

wilkerlucio20:03:13

how can I burst it?

thheller20:03:50

rm -rf .shadow-cljs/builds

wilkerlucio20:03:25

@thheller still getting the same, tried bursting and recompiling twice

thheller20:03:25

what does the main.js look like? it should contain a goog.addDependency for shadow.js and shadow.process

thheller20:03:53

I have no idea why shadow.process wouldn't exist since it shouldn't even compile if it can't find it

thheller20:03:07

are you sure you are loading the correct build?

thheller20:03:15

not some old leftover in a corrupted state?

wilkerlucio20:03:03

wait, I forgot to delete the old files thenselves as well facepalm

thheller20:03:07

oh wait .. shadow.process is not a thing anymore

wilkerlucio20:03:22

yeah, now it works, thanks 🙂

thheller20:03:25

a recompile should overwrite them

wilkerlucio20:03:47

worked after removing the compiled files, first I just deleted the cache

thheller20:03:21

weird. recompiled files should always overwrite output

thheller20:03:27

will check the logic for that

wilkerlucio20:03:29

I was thinking this kind of things happens most often when I get back to a project that I didn't ran for a while

wilkerlucio20:03:51

I was thinking if would be a good idea to store the last compilation run, and just burst everything after some amount of time (maybe 3 days or something)

lwhorton23:03:23

has anyone gotten shadow-cljs to work with vim-fireplace? Im not quite sure why, but none of the shadow-cljs tasks ever say shadow-cljs - nrepl running at localhost/127.0.0.1:8202, which makes me think I need to manually configure it to actually start an nrepl?

justinlee23:03:00

so if you start a server, the server will say what port its running on. i configure to always use port 9000 :nrepl {:port 9000}. i know thomas has been reluctant to use lein’s nrepl port file

justinlee23:03:16

but just hard coding the nrepl port has been easiest for me

thheller23:03:01

.nrepl-port is generated when it doesn't exist and the nrepl port is also always printed in the latest version

justinlee23:03:10

oh and I didn’t actually write a complete thought: if you start a server, the server prints out the nrepl, but subsequent commands do not