Fork me on GitHub
#shadow-cljs
<
2019-11-03
>
caleb.macdonaldblack04:11:00

Is there anyway to set a port in shadow-cljs.edn using an environment variable?

caleb.macdonaldblack04:11:28

I'm using #shadow/env "NREPL_PORT" however it's failing because it's gettting a string and expecting a number

caleb.macdonaldblack04:11:57

I'm trying to set the nrepl, http-server and devtools ports with env vars

thheller08:11:50

@caleb.macdonaldblack that isn't supported no. why are you trying to do that? the default is to use random ports and you looking at .shadow-cljs/nrepl.port to get the actual port

caleb.macdonaldblack08:11:53

I'm trying to run two docker-compose stacks. One for testing and one for develop where they have different DBs.

caleb.macdonaldblack08:11:18

I ended up running two instances of the web app as two shadow builds

caleb.macdonaldblack08:11:27

So I have a local test db and a local dev db. My test db can be polluted with various test data. I want my local development db not to be effected by the tests. So I need my backend running in two environment, one for dev and one for test. My front-end is compiled with the backend url baked in. So I just run two instances of my front-end with different backend urls.

caleb.macdonaldblack08:11:59

I'm running everything in docker so it's executed similar to how it is in CI

thheller08:11:00

but what does the DB have to do with shadow-cljs?

caleb.macdonaldblack08:11:56

A shadow build communicates with a test backend which communicates with a tests db

caleb.macdonaldblack08:11:16

and I want to run the test and develop build simultaneously

thheller08:11:38

I do not understand your setup

caleb.macdonaldblack08:11:45

My tests are UI tests so they navigate to web app and point & click

thheller08:11:53

what does the build have to do with which db it is talking to?

caleb.macdonaldblack08:11:42

I specify the backend url (test or dev) as a environment variable. Which is picked up in shadow-cljs as a closure-define

thheller08:11:50

and that is your mistake

thheller08:11:08

don't make it part of the build at all ... and all your problems go away

thheller08:11:33

instead as recommended create a init fn that is called on startup

thheller08:11:49

that function either takes an argument with config

thheller08:11:03

OR looks up some variable set before

thheller08:11:21

<script>your.app.init({db: "some-url"});</script>

thheller08:11:02

or <script>var MY_CONFIG = {url: "some-url"};</script> and :init-fn and it accessing js/MY_CONFIG

thheller08:11:29

that way you have ONE build that doesn't need to be recompiled when changing backends

thheller08:11:49

reducing the number of build variables that could cause issues

thheller08:11:08

so then the control is in the hands of the HTML

thheller08:11:23

so you can either create a index-test.html and index-dev.html

thheller08:11:33

or have your server create the different configs and emit different HTML

thheller08:11:56

environment variables for build config are terrible

caleb.macdonaldblack09:11:17

Okay so I was aware of everything up until the index-test.html/index-dev.html. I hadn't considered that. I always thought I would have to server side render the vars in and my front-end is not served up from my back-end. This is a good solution.

caleb.macdonaldblack11:11:20

I'm not sure what I'm doing wrong here. It seems that :push-state/index is ignored completely

caleb.macdonaldblack11:11:53

Or maybe I'm using it wrong idk.

caleb.macdonaldblack11:11:30

It's trying to server index.html

thheller11:11:00

hmm that might not work right now

caleb.macdonaldblack11:11:07

Actually no it was an issue with something else. I thought it wasn't looking for the file because the error said "Not found. Missing index.html."

caleb.macdonaldblack11:11:17

But I can see that is just hard coded in

caleb.macdonaldblack11:11:39

I didn't map the file correctly in docker-compose.

thheller11:11:55

ah yeah right. the index.html is hardcoded

teawaterwire15:11:36

i have this case where Shadow can infer type on target:browser but not on target:node-library i'm curious to understand why :thinking_face:

teawaterwire15:11:51

(browser code)

teawaterwire15:11:24

giving inference warning

thheller15:11:58

for :browser it will actually process all JS and gather externs while processing

thheller15:11:13

for :node-library it doesn't process and JS and lets node provide it

thheller15:11:38

so it can't find the val

thheller15:11:58

I maybe should not consider gathered externs for externs inference

thheller15:11:08

so the behavior is the same on all platforms

teawaterwire15:11:43

oh i see - but could we gather externs also for node?

teawaterwire15:11:38

(maybe using {:infer-externs :auto} as default would be good enough to warn the developper)

thheller15:11:10

no externs gathering for node no

thheller15:11:25

technically it could but it would just be slow

teawaterwire15:11:42

because node libraries are too big?

thheller15:11:44

IMHO externs inference is better

thheller15:11:44

no because the externs gathering is flawed. I only added it to make externs less of hassle

thheller15:11:55

externs inference fixes that in a better way though

teawaterwire15:11:12

ok got it :thumbsup:

Aleed19:11:06

is it possible to use datomic with shadow-cljs?

thheller19:11:53

datomic doesn't support CLJS? so if you mean to use it in a CLJS build then it won't work no

Aleed19:11:49

oh ok that must be the issue then. i'm using a :target node-script build

thheller19:11:40

yeah datomic only runs in Clojure. no support for CLJS as far I know.

Aleed19:11:04

is there a different build I can use to get it working with shadow? or I have to integrate another build tool

thheller19:11:40

it will not run in CLJS. no matter what you use to build it. it doesn't support node or any other JS

🆗 4
thheller19:11:14

you can build a CLJ server that talks to datomic and talk to that from CLJS but thats about it

thheller19:11:46

I don't use datomic so I'm not sure if they offer some kind of http api or so

eoliphant19:11:04

@alidcastano check out something like Pathom (and it’s datomic plugin) if you’d like a datomic’ish API for your client

🆗 4
eoliphant19:11:30

hey @thheller, running into an issue with the auth0-spa-js lib, they have a weird layout which i suspect is the problem but, not sure how to get around it

thheller19:11:18

whats the problem? looks like any other JS package?

eoliphant20:11:40

sorry stepped away, I thought there was normally an index.js or something that you’re looking for

eoliphant20:11:03

here’s their default export import createAuth0Client from "@auth0/auth0-spa-js";

eoliphant20:11:55

But (require '["@auth0/auth0-spa-js" :default createAuth0Client]) results in createAuth0Client being nil

thheller20:11:07

you probably either need :as or :refer

darwin21:11:47

hi, just wondering where is shadow-cljs sever version coming from, I’m on a mac, running shadow-cljs directly from project dir with packages.json, latest shadow-cljs is installed in node_modules and other in global yarn, but running shadow-cljs server still gives me shadow-cljs - server version: 2.8.67 running at instead of expected 2.8.69

lilactown21:11:30

Are you using deps.edn / leiningen integration @darwin?

lilactown21:11:03

It will use whatever version is in your deps.edn classpath

darwin21:11:16

ah, here you go, thanks a lot

lilactown21:11:37

Npm version is ignored when using deps or lein integration

darwin21:11:40

I don’t think so, looking at /usr/local/bin/shadow-cljs it tries to require code from node_modules first

darwin21:11:57

so node_modules version should drive initial cli version

darwin21:11:34

I have to keep them both in sync, I guess

thheller08:11:39

no real need to keep them in sync. the CLI npm package changes rarely. mostly fine to just update the clojure package

✔️ 8
eoliphant21:11:44

thanks @thheller :as did it