@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
<https://localhost>, 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?
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
OK. Any issues in that case with the cross-origin websocket connection that you know of?
OK, fantastic. Thanks very much!1👍
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…
@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.1👍
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. :simple_smile:
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 ?
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
can’t compile - have some issue w/ macro
so trying to debug what that issue is
yeah that needs log information
let me check that out
but I probably wont have a look at it until tomorrow
I appreciate feedback
I’m trying to dig a bit via the figwheel scripting API
in the repl
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
yes, that makes sense
I’m going to try and release 0.2.6 in the next half hour and it will include this
I’ll try it out though when it’s up
The new logo is kick ass.1👍
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
I’m going to add smart bundling based on index.js and npm_deps.js file next and put it behind a flag1👍1❤️
that should cover all the common cases
I’m also thinking of adding a figwheel option
: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!
Let me know if you want anything tested 🙂
are you using the :output-to and :final-output-to helpers?
No. I left what I had from the official webpack guide e.g.
:output-dir. Want me to check them out?
Okay, ran through the Quickstart and then the Other stuffs and used the
: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:
• 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
• 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.