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

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

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

@rgm have you seen this document? https://github.com/bhauman/figwheel-main/blob/master/docs/docs/vim.md

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

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

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

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

@tmarble https://github.com/bhauman/figwheel-main/issues/89

and @tmarble thanks for your feedback here its super helpful

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

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

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

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

{:main cljs-spa.test-runner}

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

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

@pesterhazy no you can’t use b with m

they are both main-opts

-m indicates execution

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

-co isn’t a main-opt

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

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

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

-co -c --serve

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

its not

completely interchangable

the build-id is more readily specified by -b

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

remember that you can supply edn options directly to -co

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

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

whereas with -b versus -bo its very clear

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

thanks for the explanation

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

piggieback doesn’t not place any requirements like this

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

I’m really confused what are you trying to do

haha me too

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

just want to understand all the moving parts

oh oh oh

yeah that is why you are having problems

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

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

its very particular

but it sounds like you got it working

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

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

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

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

but the clojurescript browser-repl is very brittle itself

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

can only handle about 20-30 evals before disconnecting

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

it is a completely different codebase

here are my invocations: https://gist.github.com/rgm/9ca138f5390e6ab43f9b36e66d821a5b

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

oh your using the figwheel repl

sorry might not have communicated that

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

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

and what goes wrong?

specifically what goes wrong?

(just getting a stack trace, one sec)

https://gist.github.com/rgm/99d8f33a75188f6f6ce5719eeb34629a

and what did you do to cause that?

what did you eval?

(enable-console-print!)

or any (def thing 'foo) …

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

so something is wrong

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

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

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

if you say js/alert

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

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

ie one buffer but not the one that requires reagent

by why not add piggieback as the instructions suggest?

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

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

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

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

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

yeah this is deps edn tho

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

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

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

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

yes,

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

if so it tries to resolve piggieback

and then start the repl with piggieback

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

there seems to be two of something running

I don’t see what your doing

@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)

you were just trying to speed up the compile

i get it

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

this is for CI

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

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

depending on what you are doing

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

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

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

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

@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

great to hear it from you.

@bhauman your suggestion (`-co common.cljs.edn:test.cljs.edn`) works: https://github.com/pesterhazy/cljs-spa-example/pull/15/files#diff-b7e76a71c7f6f632ab22cd7dfaf69f14R10

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.

@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

@tmarble Probably should just stop writing tests 🙂

hahaaha... NoTestDrivenDevelopment 🙂

@shaun-mahood this is a very good point

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

darn, that’s going to sting folks

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

for now

@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)

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

I’m all ears

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

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"]

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?

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

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)

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)

@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.

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

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.

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

without tunneling

or proxying

especially if you have experience setting up https for jetty

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.

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

that’s sounds cool as heck

pretty soon we should just default to https for local dev

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

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)

@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)

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

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.