Fork me on GitHub
#shadow-cljs
<
2019-10-26
>
thheller08:10:26

@currentoor see https://shadow-cljs.github.io/docs/UsersGuide.html#js-resolve. so :js-options {:resolve {"react-native" {:target :npm :require "react-native-web"}}}

thheller08:10:08

thats the addAlias stuff basically. dunno what the rest of it does though

currentoor14:10:48

@thheller thanks I’ll give it a shot

currentoor14:10:40

Wait but will that apply inside an npm dep or only to cljs code?

currentoor14:10:19

My understanding is it’s for cljs only

thheller14:10:38

what do you mean?

thheller14:10:47

it'll apply for every require shadow-cljs will resolve

currentoor15:10:11

Will it affect code I’m getting from node_modules?

currentoor15:10:55

I want to change the import statements in an npm dependency

thheller14:10:50

in JS and CLJS

dpsutton15:10:22

@thheller i saw the thread where you mentioned CIDER isn't starting up the best way. I'll put the two startup commands in this thread and wonder what is the preferred way it should work?

dpsutton15:10:31

(defun cider-shadow-select-cljs-init-form ()
  "Generate the init form for a shadow-cljs select-only REPL.
We have to prompt the user to select a build, that's why this is a command,
not just a string."
  (let ((form "(do (require '[shadow.cljs.devtools.api :as shadow]) (shadow/nrepl-select %s))")
        (options (or cider-shadow-default-options
                     (completing-read "Select shadow-cljs build: "
                                      (cider--shadow-get-builds)))))
    (format form (cider-normalize-cljs-init-options options))))

(defun cider-shadow-cljs-init-form ()
  "Generate the init form for a shadow-cljs REPL.
We have to prompt the user to select a build, that's why
this is a command, not just a string."
  (let* ((form "(do (require '[shadow.cljs.devtools.api :as shadow]) (shadow/watch %s) (shadow/nrepl-select %s))")
         (options (or cider-shadow-default-options
                      (completing-read "Select shadow-cljs build: "
                                       (cider--shadow-get-builds))))
         (build (cider-normalize-cljs-init-options options)))
    (format form build build)))

dpsutton15:10:58

these are the two startups. Essentially > "(do (require '[shadow.cljs.devtools.api :as shadow]) (shadow/watch %s) (shadow/nrepl-select %s))"

dpsutton15:10:07

or > "(do (require '[shadow.cljs.devtools.api :as shadow]) (shadow/nrepl-select %s))"

thheller15:10:34

one issue is that it only lists the builds that it finds in shadow-cljs.edn

thheller15:10:55

it should at least list the 2 "specials" meaning the node-repl and browser-repl

thheller15:10:06

they are not dependent on any build config

thheller15:10:14

similar to launching a default node repl for CLJS

dpsutton15:10:16

yes. we had some back and forth on that recently. its trying to be helpful. Where might other builds be located? I was trying to give an example of how that list might not be exhaustive in the future

thheller15:10:48

just add 2 hardcoded defaults, they are built-in so you don't have to list them in the config

dpsutton15:10:50

ooh, really. that never clicked for me. i had wanted that feature and didn't realize it was there the whole time 🙂

thheller15:10:56

but they are started differently

thheller15:10:06

so (shadow.cljs.devtools.api/node-repl)

thheller15:10:10

or browser-repl

dpsutton15:10:36

ok. and is it invalid for a user to define their own build named browser-repl or node-repl?

dpsutton15:10:57

ie, we can unequivocally do that when the build choice is browser-repl?

thheller15:10:02

hmm it probably should be yeah 😛

thheller15:10:11

but it isn't currently

dpsutton15:10:55

ok. and for clarity, could they be named "quick-browser-repl" or something to distinguish that if you have a proper build laid out you should probably use that?

dpsutton15:10:47

i'm assuming these are for new projects so you can get to work but not really applicable for established projects. i'd hate for someone thinking they want a browser repl and getting the default one without their stuff

thheller15:10:41

no. just assume browser-repl and node-repl to be reserved

thheller15:10:48

no one is gonna name their build that

thheller15:10:05

they are just as applicable to established projects

thheller15:10:14

it is very much like in CLJ

thheller15:10:24

you can either run lein repl

thheller15:10:41

the lein uberjar and java -cp that-uberjar.jar clojure.main -r

thheller15:10:52

both ways get you a REPL but with very different semantics 😛

dpsutton15:10:57

great analogy

thheller15:10:04

sometimes you just want a REPL and build from there

dpsutton15:10:19

thanks. i'm gonna go get this into CIDER today

dpsutton15:10:12

one more question, does that work even in the absence of shadow-cljs.edn?

dpsutton15:10:38

ok. thanks much

thheller15:10:10

well, thinking about it npx shadow-cljs server won't start without a config

thheller15:10:29

so it would only work when you connect remotely to some embedded shadow-cljs instance I guess

dpsutton15:10:17

ok. the check nil'ed out when there was no file and that sounds ok for now then as well

dpsutton15:10:38

but i'll play around with it. its possible that at the point this is run shadow is assumed already started

thheller15:10:31

dunno if this helps but browser-repl is basically just a hardcoded :target :browser build

thheller15:10:50

with one extra thing that it will try to open the browser automatically

thheller15:10:02

same for node-repl trying to run an actual node process

pez15:10:15

Calva would distinguish between a build named :node-repl and the node-repl using the leading :. But, yeah, it is inviting confusion to name your build like that. 😃

thheller15:10:18

yeah but they have to be special because they do extra stuff

thheller15:10:07

just make sure that you don't send (shadow.cljs.devtools.api/watch :browser-repl) since that'll just complain about build not found

pez15:10:59

If such a build was configured, it would work right?

pez15:10:39

@U11BV7MTK, here might be some inspiration for you. This is what Calva asks for when jacking in to a shadow-cljs project:

dpsutton15:10:41

that's the current behavior unfortunately. someone recently put the default builds in but they are sent as regular builds

pez15:10:03

And then it asks where to connect. And the user can at any point choose to connect to a different build/repl. Not sure how this would work in CIDER, but in Calva there is only one CLJS REPL at a time connected.

dpsutton15:10:04

oh it can take multiple @pez?

dpsutton15:10:31

can watch several and then nrepl select a single?

pez15:10:59

Yes, it can take multiple builds at start up, so that shadow starts watchers for all of them. Then single for the connect step.

thheller15:10:17

you can switch between REPLs at will once the watch is running

pez15:10:35

Yeah, so Calva supports that.

dpsutton15:10:42

that's quite nice. the more i use cljs tooling the more i want the magic to go away 🙂

thheller15:10:49

so if shadow-cljs browser-repl is running externally

dpsutton15:10:04

i've made a cljs-repl-type that just ensures piggieback is there and then use the api of your build tool

thheller15:10:07

you are actually allowed to (...api/nrepl-select :browser-repl)

dpsutton15:10:24

i'm not sure the auto stuff is more helpful than obscuring what tools are actually available

dpsutton15:10:44

ah interesting

pez15:10:46

Very cool. I wonder if Calva could support that in some easy way…

thheller15:10:51

I would love if more of the stuff was done via nrepl messages

pez15:10:52

Which auto stuff?

thheller15:10:02

and less via hijacking eval and hope some bindings exists

dpsutton15:10:10

the cljs startup commands. they are done for you and not displayed

dpsutton15:10:58

you'd like an explicit :cljs/eval op in nrepl rather than the way it works now?

thheller15:10:25

I'm not sure honestly. the major issue I have with nrepl is that it is built with solely CLJ in mind

thheller15:10:53

that means its "session" support is an atom that ONLY allows vars as keys

thheller15:10:09

those vars are bound in the context of eval

thheller15:10:32

but that doesn't translate to CLJS at all

thheller15:10:55

dunno ... the stuff I'm doing with the Inspect feature and shadow.remote is basically a new REPL protocol

thheller15:10:01

gave up trying to get this working with nREPL

thheller15:10:39

so I really have no idea how to make it better 😛

pez16:10:26

@thheller: I am trying to get my react-native + re-frame project up to date again. I based it on your example once. It works, but when I do yarn start after a while I get this warning:

WARNING in /Users/pez/Projects/rn-rf-shadow/node_modules/react-native/Libraries/Performance/Systrace.js 1:2947-2954
Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
 @ /Users/pez/Projects/rn-rf-shadow/node_modules/react-native/Libraries/react-native/react-native-implementation.js
 @ /Users/pez/Projects/rn-rf-shadow/app/index.js
 @ multi /usr/local/lib/node_modules/expo-cli/node_modules/react-dev-utils/webpackHotDevClient.js /Users/pez/Projects/rn-rf-shadow/app/index.js
And after that a lot of errors like this one
ERROR in /Users/pez/Projects/rn-rf-shadow/node_modules/react-native/Libraries/Animated/src/components/AnimatedImage.js
Module not found: Error: Can't resolve '../../../Image/Image' in '/Users/pez/Projects/rn-rf-shadow/node_modules/react-native/Libraries/Animated/src/components'
 @ /Users/pez/Projects/rn-rf-shadow/node_modules/react-native/Libraries/Animated/src/components/AnimatedImage.js 1:23-54
 @ /Users/pez/Projects/rn-rf-shadow/node_modules/react-native/Libraries/Animated/src/Animated.js
 @ /Users/pez/Projects/rn-rf-shadow/node_modules/react-native/Libraries/Experimental/SwipeableRow/SwipeableRow.js
 @ /Users/pez/Projects/rn-rf-shadow/node_modules/react-native/Libraries/Experimental/SwipeableRow/SwipeableFlatList.js
 @ /Users/pez/Projects/rn-rf-shadow/node_modules/react-native/Libraries/react-native/react-native-implementation.js
 @ /Users/pez/Projects/rn-rf-shadow/app/index.js
 @ multi /usr/local/lib/node_modules/expo-cli/node_modules/react-dev-utils/webpackHotDevClient.js /Users/pez/Projects/rn-rf-shadow/app/index.js
Any idea where I should look for the source of these? Things still work, but it is hard to develop with all those errors…

thheller16:10:15

@pez looks to me like you have the hot-reload stuff from react-native enabled. that still needs to be disabled.

thheller16:10:39

otherwise those are all errors from inside neact-native internals so I have no clue. none of those sources are processed by shadow-cljs.

pez17:10:21

Thanks, I’ll figure it out.

darwin22:10:39

running shadow-cljs start from command line works without warnings, but when I try to run (shadow.cljs.devtools.server/start!) from my test runner I get a ton of warnings about “<xxx> provide conflict for <yyy>” I made sure I’m running it from the same dir, not sure where would be a difference. Thanks for help.

thheller22:10:27

you get those warnings too for start, they just end up in the .shadow-cljs/*.log files

thheller22:10:47

start starts in the background, you'd get them with shadow-cljs server too

thheller22:10:35

provide conflicts just mean that something on your classpath is duplicated

darwin22:10:25

ok thanks, I will hunt it down, it looks like my compiled assets are on the classpath for some reason

darwin22:10:04

and when I have you here, it would be handy for me to use :lein option in shadow-cljs.edn, it works from command-line, but seems to be ignored when running as a library

darwin22:10:45

just wanted to get confirmation

thheller22:10:01

not sure what you are asking

thheller22:10:31

when running as a library you already started it so the :source-paths and :dependencies or :lein in shadow-cljs.edn don't matter at all

thheller22:10:44

they are only used when you use shadow-cljs itself to start things?

darwin22:10:32

shadow.cljs.devtools.api/watch etc. seems to be reading shadow-cljs.edn as-is, without looking at :lein or doing anything about it

thheller22:10:51

I don't understand what you are talking about sorry

thheller22:10:55

what do you expect?

thheller22:10:11

of course it won't look at :lein, it is already running?

thheller22:10:03

watch will read the config file yes, it must get the :builds entries

darwin22:10:45

hm, maybe I’m misunderstanding whole client-server architecture of shadow-cljs, I want to run it inside my JVM alongside my other stuff

thheller22:10:03

yes. you did that when running server/start!

darwin22:10:05

so I can call shadow.cljs.devtools.api/get-worker and get repl-state from there

thheller22:10:44

your JVM is now the shadow-cljs server

darwin22:10:44

ah, I mean build-state, for shadow.cljs.repl commands

darwin22:10:12

ok, good, but when I start it this way, it won’t respect :lein correct?

thheller22:10:28

you are confusing the heck out of me right now

thheller22:10:40

what effect would :lein even have at that point?

thheller22:10:51

YOU started a JVM that you called start! in

darwin22:10:56

it would give :source-paths and :dependencies

thheller22:10:17

no other JVM will be started. your :source-paths and :dependencies apply from however you started YOUR JVM

thheller22:10:29

thats the point of embedded mode 😛

darwin22:10:15

ok, now I get it, I thought it was doing some dynamic classpath stuff

thheller22:10:06

no, nothing at all. I experimented with that a bit but that was causing nightmares when running inside lein or boot or clj. basically anything where shadow-cljs wasn't in full control of the JVM

darwin22:10:45

ok, thanks for your help, will try to move forward, working on that dirac integration

thheller22:10:49

you might be interested in the plugin stuff I have sort of sketched out but never quite finished

thheller22:10:52

so you could run inside shadow-cljs maybe? seems a weird route to embed shadow-cljs in diract? you don't embed figwheel right? connect to nrepl instead?

thheller22:10:00

or is this just for testing stuff?

thheller22:10:07

I would probably advise not working on this right now. the shadow.remote stuff I'm using for the Inspect stuff will most likely become part of the "official" API

thheller22:10:45

and it will contain many parts that you'll likely need that aren't really otherwise exposed right now

darwin22:10:24

if shadow.remote is what I think it is, I would like that approach, I would connect to well-known port to shadow-cljs server and ask it to convert cljs-source -> js-source for me

darwin22:10:39

like you would do in your web repl

thheller22:10:04

yes, that will be part of it indeed

darwin22:10:46

I just hit a show stopper in the approach I wanted to do, you patched clojurescript compiler, so I cannot have normal compiler and shadow-cljs living in peace in the same JVM

thheller22:10:14

yeah thats gonna get you in trouble

thheller22:10:09

although I tried to be non-invasive and just add stuff that won't do anything when using the cljs.compiler directly

darwin22:10:13

this remote approach will be much more flexible

darwin22:10:42

I will just need support for :locals and querying current ns