@gdanov I’m also available here if you want to talk more about the contains problem

Sorry if this has been asked already, but I'm having issues with my Figwheel environment now that browsers don't send cross-origin cookies without the Secure attribute set.

(And I'm running stuff on , not , so the Secure attribute is a no-go.)

I have Figwheel serving my frontend and a backend running in a different process, listening on a different port, so I'm hitting the cross-origin cookie security policy.

Here's an SO question I posted yesterday about this. Not about Figwheel per se, but about this issue: https://stackoverflow.com/questions/62013644/how-can-i-bypass-samesite-cookie-restrictions-in-my-development-environment

I guess I need to either figure out how to use https on localhost or else bundle the frontend and backend together so that they appear to the browser to come from the same origin.

Anyway, anybody figured this out for Figwheel yet?

@jeff.terrell hmm this is interesting

but the answer here is to have your backend serve your front end

Yeah it was a real stumper for me last week. 😅

figwheel still runs on localhost to supply reload and repl connection

Ah…like start Figwheel and keep it running, but actually access the site via the backend.

but you have to compile the files and serve the static files from your backend server

https://figwheel.org/docs/your_own_server.html

OK. Any issues in that case with the cross-origin websocket connection that you know of?

nope 🙂

OK, fantastic. Thanks very much!

You may need to configure your csp if you have one

Most secure defaults would block access to the Figwheel one

I definitely read the "Your Own Server" page before. Is it recommending this approach, to actually load your page from the backend server? If so, I missed it. I thought it was saying that it was fine to load frontend from Figwheel and backend from a separate origin. Anyway…

@dominicm - Gonna look into this CSP thing…thanks.

@jeff.terrell yeah I just re-read it, I’ll have to have another look at it. It creates a server that serves the whole application including that static assets but its all implicit.

its definitely not making the point I want to make

I'm relieved to hear you say that, so I'm not just missing it.

@dominicm what to you mean by CSP?

cross site policy?

@bhauman yeah. You have to specify where connections are allowed to.

oh yeah coming back to me 🙂

Mistakenly posted to #lein-figwheel originally: when figwheel-main fails with a cljs compilation issue - it reports the logs with no stacktrace. is there anyway to get more? example: `[Figwheel:SEVERE] java.lang.IllegalArgumentException: Don't know how to create ISeq from: clojure.lang.Symbol` but no access to more of the stack

did you try :log-level :all ?

@mikerod ^

@bhauman trying it out - no, haven’t configured that option before

I got more output from it being set in other places - but still no stacktrace for the error or more info on the error

I know the error happens during macroexpansion while compiling cljs

is it the initial compile?

or in the watched compile?

it seems like the watched compile handles the stacktrace better

initial

can’t compile - have some issue w/ macro

so trying to debug what that issue is

hmmm

yeah that needs log information

let me check that out

thanks

but I probably wont have a look at it until tomorrow

that’s ok

I appreciate feedback

I’m trying to dig a bit via the figwheel scripting API

in the repl

@mikerod actually I found it

let’s see if I can get it in the 0.2.6 release

basically whenever I call log/error I need to call log/debug with a stacktrace

nice

yes, that makes sense

I’m going to try and release 0.2.6 in the next half hour and it will include this

Very fast!

I’ll try it out though when it’s up

@mikerod its up and use :log-level :debug

The new logo is kick ass.

nice, I’ll try it out soon @bhauman thanks for quick turnaround

@mike858 Thanks! spent the weekend starting to implement a new design from @lubovsoltan

figwheel-main 0.2.6 has been released this features a much nicer workflow for using NPM, I’ve started the docs for it here https://figwheel.org/docs/npm.html

autotesting and extra-mains are supported

it logs the bundle command so that you can see when its happening

How frequently is it run now?

it runs once at the beginning, but if you set :bundle-once false it runs every time

@dominicm ^

I’m going to add smart bundling based on index.js and npm_deps.js file next and put it behind a flag

that should cover all the common cases

I’m also thinking of adding a figwheel option :auto-bundle :webpack to handle the most common case so that folks don’t have to configure anything really

@dominicm if you get a chance to use it let me know, any feedback is helpful

I'll probably set it up tomorrow

With that and install deps, I've got a pretty nice setup

yeah I’d like to see what you’ve set up

I’m really looking forward to the $ syntax as that really completes the story

Just upgraded some non trivial projects to latest. Works great. Thanks, Bruce!

@tkjone awesome! Thanks!

Let me know if you want anything tested 🙂

are you using the :output-to and :final-output-to helpers?

@tkjone ^

No. I left what I had from the official webpack guide e.g. :output-to and :output-dir. Want me to check them out?

@tkjone yeah if you could give the new NPM guide a gander and check if its functionality works for you that would be great https://figwheel.org/docs/npm.html

Okay, ran through the Quickstart and then the Other stuffs and used the :output-to and :final-output-to helpers helpers. Sleek.

Given my assumption is that the people using this are anywhere from early learners -> experienced developers these are some of the items I might enhance:

Quickstart • Maybe because the title of the section is smaller, I did not immediately realize it was an official quick-start 😆 • If people are coming from the official webpack guide -> this guide they might trip up around the fact that they don’t have to specify the output-to and output-dir • Linked to the above bullet, I only realized after reading the Figwheel message in the command line that the file output by webpack is called main_bundle.js as opposed to main.js . This is partly from following the official guide and quickly adapting it to your guide. Maybe adding a quick note about the name of the file output in the quickstart section could be helpful :thinking_face: • The yellow comment block in the quickstart is super helpful, but I had to re-read it a few times to fully grok what I think is the suggestion: if you happened to have specified an :output-dir please make sure that :output-to is updated accordingly.