This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (7)
- # babashka (42)
- # beginners (349)
- # chlorine-clover (9)
- # cider (16)
- # circleci (2)
- # clj-kondo (6)
- # cljs-dev (61)
- # cljsrn (15)
- # clojure (95)
- # clojure-europe (11)
- # clojure-italy (2)
- # clojure-nl (4)
- # clojure-spec (4)
- # clojure-uk (24)
- # clojurescript (21)
- # conjure (2)
- # core-async (8)
- # cursive (12)
- # datascript (2)
- # emacs (4)
- # exercism (1)
- # figwheel-main (86)
- # fulcro (27)
- # graalvm (4)
- # helix (36)
- # hoplon (3)
- # interop (44)
- # kaocha (6)
- # lein-figwheel (4)
- # malli (7)
- # meander (9)
- # off-topic (95)
- # pathom (33)
- # pedestal (13)
- # re-frame (20)
- # reitit (3)
- # shadow-cljs (102)
- # tools-deps (14)
- # xtdb (16)
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.
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.
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?
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.
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
I got more output from it being set in other places - but still no stacktrace for the error or more info on the error
@bhauman I tried out the new version with debug logging and it gives me a lot more useful information. Awesome. Thanks again.
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
I’m going to add smart bundling based on index.js and npm_deps.js file next and put it behind a flag
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
Just upgraded some non trivial projects to latest. Works great. Thanks, Bruce!
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.