This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-05-27
Channels
- # admin-announcements (1)
- # announcements (1)
- # babashka (16)
- # beginners (222)
- # bristol-clojurians (6)
- # calva (13)
- # cestmeetup (5)
- # cider (19)
- # cljs-dev (2)
- # cljsrn (4)
- # clojure (65)
- # clojure-europe (31)
- # clojure-nl (1)
- # clojure-norway (1)
- # clojure-uk (33)
- # clojurescript (64)
- # community-development (5)
- # core-async (18)
- # cursive (15)
- # datomic (6)
- # devcards (1)
- # emacs (18)
- # figwheel-main (102)
- # fulcro (51)
- # graalvm (2)
- # helix (8)
- # instaparse (33)
- # jobs (8)
- # jobs-discuss (3)
- # leiningen (42)
- # off-topic (88)
- # pedestal (15)
- # re-frame (18)
- # reagent (26)
- # reitit (15)
- # rum (3)
- # shadow-cljs (119)
- # spacemacs (9)
- # sql (2)
- # tools-deps (7)
Everything works. The guide is great. The only possible items of confusion might be in the QuickStart.
I know that is a balancing act though because it’s easy to say too much too early
Hope that helps 🙂
is it possible to get the benefits of figwheel's :auto-testing
(i.e. automatic detection/injecting of test namespaces) while supplying a custom test runner namespace?
I'd like to provide instructions for people on how to use chui (https://github.com/lambdaisland/chui) with Figwheel, so far I've only tested it with shadow-cljs
but it relies quite heavily on the fact that shadow injects your test namespaces as dependencies of the runner ns. If you need to manually require all those tests that's not a great user experience. I was wondering if it's possible to do the same figwheel, or maybe even if it's something to lobby for at the cljs compiler level.
@plexus these instructions should work right? https://figwheel.org/docs/testing.html#custom-testing-with-extra-main-files
@plexus I think I need to make a utility macro to allow you to pull all of the test namespaces. But you could give folks instructions where they supply the namespaces as well right?
@bhauman yeah I read those instructions, but they mention requiring your test namespaces manually, which worried me a bit :)
chui has a macro which collects information about test vars from the compiler env, so it's important that that only gets compiled after all the test namespaces are compiled.
on shadow we can supply the runner namespace as part of chui, but then shadow implicitly does the requires, so those test namespaces are compiled first
users would have to copy that runner namespace into their own projects to be able to add requires manually
@plexus if I provided you a helper that returned the test-namespaces at cljs runtime, that’s all you need right?
uh you'll have to walk me through here. How would that work? Would that allow me to then require those namespaces automatically?
yeah that's really the crux of the matter here. We collect pretty detailed information about test vars from the compiler env, but to do that we have to be sure that all test namespaces have been compiled first, so they need to implicitly (or explicitly) required before that macro that collects test information runs.
hmmm I’ll need to reflect on this, but there should be a strategy where you can use chui with cljs.main right?
yeah same issue... which is why I was thinking maybe this conversation should be had in #cljs-dev, not sure how receptive they'll be over there 🙂
I mean people can always supply their own main ns that just calls into chui, and do manual requires, that always works
Something unclear to me from reading the new npm page in isolation is what my :output-to should be set to? Should it be set to the name of the file I am serving (frontend.js) or the name of the file I'm currently passing to webpack (index.js). I suspect it should be frontend.js, and the :output-to used in the bundle-cmd is not the :output-to I set in my config, but that's a bit confusing :)
I should read more carefully :) > Figwheel adds some additional functionality to the :bundle-cmd. It interpolates the keywords :output-to and :final-output-to into the command. In this case the :output-to is going to be replaced by the default :output-to path target/public/cljs-out/dev/main.js. The :final-ouput-to is replaced by the default value of :output-to with a bundle added before the extension or target/public/cljs-out/dev/mainbundle.js. Having said that, I'm not sure this way makes sense either :).
I think most uses are going to have/want to specify the :final-output-to if they don't want to leak "internal details" of their build throughout.
I also don't care about :output-to at all anymore. It's just a transient file. It could be in /tmp/ for all I care.
{:output-dir "target/dev/public/frontend.out",
:language-out :es5,
:asset-path "/frontend.out",
:bundle-cmd {:none ["npx" "webpack" "--mode=development" :output-to "-o" :final-output-to]},
:final-output-to "target/dev/public/frontend.js",
:target :bundle,
:main frontend.main}
But I told it to put it somewhere else :)you can override that with :final-output-to
figwheel-option or just add it do the command
but you could just skip final-output-to and put it directly in the command because your not using the default repl or extra-mains etc
Well, I'm 22 loc lighter (as I no longer build a process for webpack in watch mode). So I'm pretty happy :)
Looking forward to free optimizations to come downstream around npm_deps.js caching & such.
> I’m going to add smart bundling based on index.js and npm_deps.js file next and put it behind a flag
@dominicm I’ve been thinking a lot about the jetty conflicts that people experience so often, I’d love to be able to get away from that
@bhauman not sure if you're tracking ring 2.0 or not, but I think your life will be better once it's out
The adapter most people use is jetty, yeah. But this should make it easier to swap between servers.
or just rolling a simple server by hand and using long polling instead of websockets as it works just fine
yeah and it would pretty be straight forward to add long polling comet stuff to that and then we’re out of the websocket game
It's a shame IE never added official support for server sent events, it's much simpler of a protocol than WS
SSE has lots of nice properties, like automatic reconnection based on network conditions. All handled by the browser.
yeah, but the nice thing about websockets is they are supported in react-native, node.js, browser etc. can we say that about SSE?
https://github.com/EventSource/eventsource third party client.