Fork me on GitHub
#figwheel-main
<
2018-09-19
>
bhauman10:09:50

@tmarble so when you are using figwheel to run a --main why are you wanting to change the output-to and the output-dir?

bhauman10:09:58

and if you did the output-to and output-dir and asset-path would all have to be correctly related to the classpath so that it can be served by the browser

bhauman10:09:16

that being said there may be a bug here in how I treat :output-dir and :output-to for --main I will need to take a look

bhauman11:09:06

piggieback middleware has to be in the nREPL server when its starts

bhauman11:09:55

that middleware *enables* the launching of a ClojureScript REPL over nREPL so that REPL interaction works as expected

bhauman11:09:31

the ClojureScript environment and REPL don’t exist until you start the REPL

bhauman11:09:17

in Relation to VIM this really just means that an nREPL server needs to be started with piggieback and cider middleware installed

bhauman11:09:43

and @tmarble thanks for your feedback here its super helpful

pesterhazy11:09:47

Can I use -b with -m? I'm getting this error message:

["-b" "common:test" "-m" "cljs-spa.test-runner"]

pesterhazy11:09:01

-m should be one of: "--repl", "--serve", "-r", "-s"

pesterhazy11:09:44

I tied setting :main in my file.cljs.edn instead:

{:main cljs-spa.test-runner}

pesterhazy11:09:19

but that doesn't seem to actually ensure that cljs-spa.test-runner/-main is called (are these two different notions of "main"?)

pesterhazy11:09:48

The context is that I'm trying to move configuration into my test.cljs.edn as @bhauman suggested above. Diff here if that helps: https://github.com/pesterhazy/cljs-spa-example/pull/15/files

bhauman11:09:44

@pesterhazy no you can’t use b with m

bhauman11:09:52

they are both main-opts

bhauman11:09:05

-m indicates execution

bhauman11:09:48

you can do this though -co common.cljs.edn:test.cljs.edn -m cljs-spa.test-runner

bhauman11:09:58

-co isn’t a main-opt

bhauman11:09:17

and yes they are two different notions of main. -m exectures a my-namespace/-main function and the :main creates a bootstrap script the requires the given namespace

pesterhazy11:09:40

ah I didn't know that you could chain cos like that

pesterhazy11:09:30

so -b is like -co plus --serve?

bhauman11:09:27

-co -c --serve

pesterhazy11:09:28

I'm asking because - except for the fact that yo drop the .cljs.edn part - -co and -b seems almost interchangeable

bhauman11:09:41

completely interchangable

bhauman11:09:07

the build-id is more readily specified by -b

bhauman11:09:03

when the compiler-options -co aren’t in a file named .cljs.edn then getting a build id is dicey

bhauman11:09:04

remember that you can supply edn options directly to -co

bhauman11:09:40

when I get a -b option I really know what someone is trying to do

bhauman11:09:10

when I get a -co plus -c it can be hard to know what people are expecting, should figwheel be injected or not etc

bhauman11:09:14

whereas with -b versus -bo its very clear

pesterhazy13:09:26

ah -co can be an EDN string as well - also didn't know that

pesterhazy13:09:30

thanks for the explanation

rgm13:09:06

@bhauman yea, I’ve been working from that document 👍 . I documented some of my confusion over in #vim : https://clojurians.slack.com/archives/C0DF8R51A/p1537288231000100

bhauman13:09:47

piggieback doesn’t not place any requirements like this

rgm13:09:00

the thing that has been confusing me is that I didn’t add the middleware, BUT I can (js/alert "hi") without it from Vim

bhauman13:09:02

I’m really confused what are you trying to do

rgm13:09:05

haha me too

rgm13:09:39

hook up a browser repl end-to-end by myself so I can figure it out and deal with occasional brittleness

rgm13:09:52

just want to understand all the moving parts

bhauman13:09:24

yeah that is why you are having problems

rgm13:09:26

I’m throwing that foreign-libs wrench into the works

bhauman13:09:59

the foreign libs isn’t the problem the clojurescript browser repl is the problem

bhauman13:09:18

its very particular

bhauman13:09:53

but it sounds like you got it working

rgm13:09:34

I seem to have, yeah, but I’m whacking up hard against the browser repl seeming to know nothing about react, et al.

rgm13:09:53

ie. it works in one namespace w/o react required but not the other

rgm13:09:29

also, I don’t think I explicitly did anything to wrap piggieback anywhere and yet Vim is still plumbed in semi-ok

bhauman13:09:42

@rgm this is a good exercise if you really want to go all the way down the rabbit whole

bhauman13:09:09

but the clojurescript browser-repl is very brittle itself

rgm13:09:17

haha this is one of those “capacity-building” exercises, you might say

bhauman13:09:24

can only handle about 20-30 evals before disconnecting

rgm13:09:20

is figwheel repl-env on top of the clojurescript browser-repl or is it something else?

bhauman13:09:41

it is a completely different codebase

rgm13:09:46

I open a repl with clj and then (start-nrepl-server!) (start-figwheel) (start-cljs-repl)

bhauman13:09:50

oh your using the figwheel repl

rgm13:09:04

sorry might not have communicated that

rgm13:09:10

and then in vim :Piggieback (figwheel.main.api/repl-env "dev")

rgm13:09:37

as long as I’m in a namespace that doesn’t refer to any foreign-libs the fireplace connection is working correctly

bhauman13:09:36

and what goes wrong?

bhauman14:09:17

specifically what goes wrong?

rgm14:09:49

(just getting a stack trace, one sec)

bhauman14:09:28

and what did you do to cause that?

bhauman14:09:35

what did you eval?

rgm14:09:46

(enable-console-print!)

rgm14:09:19

or any (def thing 'foo)

bhauman14:09:20

anyway from the looks of it, it seems like the REPL that you have in vim is using a different compiler context

bhauman14:09:33

so something is wrong

bhauman14:09:49

and the fact that you are not explicitly adding piggieback is suspect

rgm14:09:23

yeah, I couldn’t figure out why it’s working at all; I don’t think it’s nashorning.

bhauman14:09:26

by the way when you use figwheel-main you will never want to use (enable-console-print!)

bhauman14:09:47

if you say js/alert

bhauman14:09:01

and it shows up in the browser then you aren’t using nashorn

rgm14:09:18

ok, so yeah, it’s working in one namespace but not the other.

rgm14:09:30

ie one buffer but not the one that requires reagent

bhauman14:09:59

by why not add piggieback as the instructions suggest?

bhauman14:09:30

vim fireplace is always nutty to me an I can never trust what its doing

bhauman14:09:57

and start from scratch and make sure there are no other nREPLs to connect to

rgm14:09:05

hm, I think I went down a rabbit hole of trying to grok why it works at all and forgot that was an option.

bhauman14:09:47

if there is a project.clj in the directory vim will start a repl from that

bhauman14:09:06

and if you have the right deps you might get a connection

rgm14:09:11

yeah this is deps edn tho

bhauman14:09:57

yeah I’m just saying that if there is a project.clj vim will try and use it, this isn’t a problem if there isn’t one there at all

rgm14:09:53

anyway that answers my question … figwheel’s not doing anything implicit around piggieback

bhauman14:09:43

if you are in an nREPL repl figwheel will start its repl using piggieback

rgm14:09:28

ohhh ok is that what all that ns-resolve stuff is doing when I grepped thru for piggieback in the figwheel.main ns?

bhauman14:09:05

it checks to see if we are currently in an nRELP session

bhauman14:09:14

if so it tries to resolve piggieback

bhauman14:09:26

and then start the repl with piggieback

rgm14:09:42

ok, please forgive my utter confusion … am I screwing things up by starting an nrepl myself at the tools.deps repl?

rgm14:09:55

there seems to be two of something running

bhauman14:09:34

I don’t see what your doing

tmarble14:09:44

@bhauman Thanks for your feedback.. some followup... I was setting output-dir and output-to simply to minimize the delta been the options previous used for lein-cljsbuild... but I'm happy to drop them... Let me try and align asset-path (in the template example) and see if it seems there's a bug there (i.e. #89, #86)

bhauman14:09:28

you were just trying to speed up the compile

bhauman14:09:04

but hopefully you aren’t running this on the command line often?

bhauman14:09:09

this is for CI

bhauman14:09:30

if you want autotesting on the command line this would be a different thing

bhauman14:09:58

and having tests run on cached code seems like a bad idea

bhauman14:09:09

depending on what you are doing

rgm14:09:11

hey Bruce I gotta run but thanks so much for looking into this … I’ll try manually wrapping a piggieback at this line and debug further: https://gist.github.com/rgm/9ca138f5390e6ab43f9b36e66d821a5b#file-repl-clj-L16

tmarble15:09:35

at the risk of stating something obvious I added a comment https://github.com/bhauman/figwheel-main/issues/89#issuecomment-422839587

jaharapi15:09:24

thanks @bhauman, it seem you are moving us to the right direction, the holy grail of web development

jaharapi15:09:34

is there any progress on figwheel-main on react native?

bhauman15:09:44

@jaharapi not yet, but my next gig is probably going to be using react-native so that will most likely lead to changes in figwheel-main

jaharapi15:09:27

great to hear it from you.

shaun-mahood17:09:23

I discovered a potential gotcha for new users (if they're trying to do too many things at once like me) - I was getting figwheel-main put into an already existing application as well as replacing component with integrant, and at come point I messed up my project.clj and ended up putting :resource-paths ["target"] in the wrong place where it ended up getting included in the uberjar. Since the uberjar was going into target, it included itself and kept growing and growing. Not a figwheel-main or integrant issue at all, but it's the first thing I've used in CLJS where target is used this way.

tmarble17:09:36

@shaun-mahood that's a good point! Esp. because if target is not in resource-paths then *should-add-temp-dir? is true causing the output-dir* to move to a temp dir which is outside of the the resources served up by the webserver on localhost:9500 -- and thus the tests will fail

shaun-mahood17:09:49

@tmarble Probably should just stop writing tests 🙂

tmarble17:09:49

hahaaha... NoTestDrivenDevelopment 🙂

bhauman19:09:34

@shaun-mahood this is a very good point

bhauman19:09:25

I’m probably going to have to change the output-dir

bhauman19:09:46

darn, that’s going to sting folks

bhauman19:09:46

@shaun-mahood you can set :target-dir to something else in the figwheel options

shaun-mahood19:09:11

@bhauman Yeah, I got it sorted as far as getting the uberjar to build (it works as long as your profiles are all set up correctly)

bhauman19:09:13

if someone has a good idea on how to transition to another default :target-dir

bhauman19:09:20

I’m all ears

shaun-mahood19:09:39

What were the big issues with how lein-figwheel did things?

tmarble20:09:24

I'm working on the uberjar task for my project right now... and NOT setting :resource-paths ["target"] b/c it does not need to be served (for dev or test purposes). So far I've realized I have to figwheel-main from a :dev dependency to a :provided dependency (otherwise it's not availble for the prep-tasks of uberjar -- which in my case includes ["run" "-m" "figwheel.main" "--build-once" "prod"]

bhauman20:09:12

oh this is an interesting side effect of using :aliases, hmmm @shaun-mahood you said you you got it sorted do you have some advice for @tmarble?

bhauman20:09:36

hopefully we will have enough information to write a good guide on this

tmarble20:09:45

indeed i'm working my way up to a full dual CLJ + CLJS REPL environment (for both CIDER and Cursive) with testing and prod (uberjar)

tmarble20:09:52

one little detail will be figwheel (in dev) running on 9500 while the "server" side process will be listening on 3333 (first pass at this didn't seem to reload on 3333, but I haven't tried debugging it yet)

shaun-mahood21:09:52

@tmarble Ooh, that sounds nice - I've been integrating it with Integrant, so it's running using the scripting API. Single repl right now but can start and stop the figwheel repl as needed. I was planning on just using cljsbuild for the production config, but it would be nicer to use figwheel for that.

tmarble21:09:53

i will use integrant too! i am quite thrilled to drop cljsbuild

shaun-mahood21:09:22

Integrant is awesome - I've got it running for dev mode right now with JDBC and connection pooling, a jetty server, reitit for the handler (with swagger API), and figwheel for dev. Production build is all working over https (except for the cljs part). I'm using environ to get my profile info, all the figwheel build info is in my integrant config, and the integrant config is in a CLJ file (no .edn files anywhere). It's certainly not perfect yet but my favourite setup so far for full-stack development. Let me know if there's anything you want me to post since it sounds like we're working on different parts of the same thing.

bhauman21:09:52

@shaun-mahood @tmarble it should be very possible to to get HTTPS working with figwheel

bhauman21:09:29

without tunneling

bhauman21:09:38

or proxying

bhauman21:09:25

especially if you have experience setting up https for jetty

shaun-mahood21:09:44

I think it's working in dev for me, I'll test it when I have a chance - I just have focused on making sure it works in the production mode.

shaun-mahood21:09:05

(Unrelated to figwheel, I figured out how to get a letsencrypt certificate for a local site using acme.sh and it's fantastic)

bhauman21:09:56

that’s sounds cool as heck

bhauman21:09:11

pretty soon we should just default to https for local dev

bhauman21:09:02

I’d like to include a certificate for local dev on localhost in figwheel

shaun-mahood21:09:49

Yeah, it's pretty fantastic - I think I should be able to get it into a single docker deployment that packages the uberjar / clojure and the letsencrypt package, so the whole thing is nice and easy to deploy (just got a new hyperconverged server at work that should be able to run docker images directly so I really want to try it out - without docker it's just as easy but I don't want to have to manage another server)

shaun-mahood23:09:56

@bhauman Not sure this is the way you were thinking, but I can confirm that figwheel is working for me with HTTPS. I included the figwheel JS file in the page my ring handler is serving and it all communicates fine (using :serve mode, can start and stop the cljs-repl and communicate with the client the same as using HTTP)

bhauman23:09:03

@shaun-mahood that’s awesome, did you have to configure the connect-url so that it started with wss ?

shaun-mahood23:09:21

Nope - pretty sure the only thing I changed to get it to work was the open-url, serving the cljs files from my ring handler, and including the js file for my build in my page.