This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-10-26
Channels
- # announcements (9)
- # babashka (98)
- # beginners (52)
- # boot (2)
- # calva (19)
- # cider (58)
- # clj-kondo (4)
- # cljdoc (11)
- # clojure (49)
- # clojure-dev (12)
- # clojure-nl (3)
- # clojure-uk (4)
- # clojurescript (42)
- # core-async (6)
- # cursive (9)
- # data-science (1)
- # fulcro (23)
- # jobs-discuss (2)
- # nrepl (30)
- # off-topic (42)
- # pedestal (6)
- # re-frame (8)
- # reitit (7)
- # remote-jobs (2)
- # shadow-cljs (134)
- # specter (1)
- # vim (13)
@currentoor see https://shadow-cljs.github.io/docs/UsersGuide.html#js-resolve. so :js-options {:resolve {"react-native" {:target :npm :require "react-native-web"}}}
@thheller thanks I’ll give it a shot
Wait but will that apply inside an npm dep or only to cljs code?
My understanding is it’s for cljs only
Will it affect code I’m getting from node_modules?
I want to change the import statements in an npm dependency
Awesome
thanks
@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?
(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)))
these are the two startups. Essentially > "(do (require '[shadow.cljs.devtools.api :as shadow]) (shadow/watch %s) (shadow/nrepl-select %s))"
or > "(do (require '[shadow.cljs.devtools.api :as shadow]) (shadow/nrepl-select %s))"
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
just add 2 hardcoded defaults, they are built-in so you don't have to list them in the config
ooh, really. that never clicked for me. i had wanted that feature and didn't realize it was there the whole time 🙂
ok. and is it invalid for a user to define their own build named browser-repl
or node-repl
?
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?
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
so it would only work when you connect remotely to some embedded shadow-cljs instance I guess
ok. the check nil'ed out when there was no file and that sounds ok for now then as well
but i'll play around with it. its possible that at the point this is run shadow is assumed already started
dunno if this helps but browser-repl
is basically just a hardcoded :target :browser
build
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. 😃
just make sure that you don't send (shadow.cljs.devtools.api/watch :browser-repl)
since that'll just complain about build not found
@U11BV7MTK, here might be some inspiration for you. This is what Calva asks for when jacking in to a shadow-cljs project:
that's the current behavior unfortunately. someone recently put the default builds in but they are sent as regular builds
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.
Yes, it can take multiple builds at start up, so that shadow starts watchers for all of them. Then single for the connect step.
that's quite nice. the more i use cljs tooling the more i want the magic to go away 🙂
i've made a cljs-repl-type that just ensures piggieback is there and then use the api of your build tool
i'm not sure the auto stuff is more helpful than obscuring what tools are actually available
I'm not sure honestly. the major issue I have with nrepl is that it is built with solely CLJ in mind
dunno ... the stuff I'm doing with the Inspect feature and shadow.remote
is basically a new REPL protocol
@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…@pez looks to me like you have the hot-reload stuff from react-native enabled. that still needs to be disabled.
otherwise those are all errors from inside neact-native internals so I have no clue. none of those sources are processed by shadow-cljs.
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.
you get those warnings too for start
, they just end up in the .shadow-cljs/*.log
files
ok thanks, I will hunt it down, it looks like my compiled assets are on the classpath for some reason
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
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
shadow.cljs.devtools.api/watch
etc. seems to be reading shadow-cljs.edn as-is, without looking at :lein or doing anything about it
hm, maybe I’m misunderstanding whole client-server architecture of shadow-cljs, I want to run it inside my JVM alongside my other stuff
no other JVM will be started. your :source-paths
and :dependencies
apply from however you started YOUR JVM
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
you might be interested in the plugin stuff I have sort of sketched out but never quite finished
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?
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
and it will contain many parts that you'll likely need that aren't really otherwise exposed right now
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
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