This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (14)
- # aws (27)
- # beginners (10)
- # boot (152)
- # cljsrn (3)
- # clojure (93)
- # clojure-hk (4)
- # clojure-russia (35)
- # clojure-switzerland (1)
- # clojurecup (1)
- # clojurescript (146)
- # core-async (23)
- # cursive (2)
- # devcards (1)
- # editors (1)
- # hoplon (28)
- # jobs-rus (4)
- # ldnclj (3)
- # leiningen (3)
- # luminus (2)
- # off-topic (4)
- # om (174)
- # re-frame (1)
- # slack-help (5)
updating boot fixed the error 😃 i was on 2.2.0 via homebrew. didn’t realize it was outdated.
on that note, as a continuation of my parinfer quest, i've just realized that Visual Studio Code has just been open sourced aaand got an official plugin system too https://code.visualstudio.com/updates that makes it a serious alternative to sublime actually... despite being a full blown ide, it's quite frugal still. might be a light weight alternative to cursive...
No - I think it’s a great way to get noobies using clojure w/o having to learn emacs/paredit
Yeah - smartparens works pretty well for me. Off topic for the #C053K90BR channel - how are you liking spacemacs?
and my workflow is more buffer based, and i couldn't get a good way to swap buffers without a lot of keystrokes
the only problem with vim is that the package mangers have no concept of transitive dependencies
Seems to me that
boot should be included in the clojurescript Quick Start and Dependencies sections.
Seeing increasing “Yeah I switched to boot and clojurescript builds are so much more approachable.” in #C03S1L9DN channel.
Yeah but there is a big pull to figwheel/devcards in the community — need a solid story there for
been mostly working on the 2.5.0 release of boot when i have a minute for recreational programming
I think there is an impression that if people leave lein or homemade scripts for boot - they loose figwheel.
Not yet. I haven't had time or incentive to work on Boot-reload as it's working well enough for me.
If figwheel isn’t really getting additional features - then makes sense to just leave well enough alone.
Probably boot-reload and boot-cljs-repl will be integrated into boot-cljs and then renaming that wouldn't make sense
But there could be a way to add deps to cljs compiler pod through cljs.edn perhaps
It will need to use Closure so I doubt writing Closure JS would make it any faster
There bunch of problems with current implementation that break reloading in some cases
just whatever produces the js files should annotate the fileset with the info reload needs
Hmh, using metadata on fileset could be useful, might help with some of the problems, like only reloading JS files belonging to the open application
Still, I have little interest in fixing things that have been already solved in Figwheel client code
I could but I don't want to. Generating it in the code makes it trivial to add cache-busters and to enable development tools with environment variables.
I think it makes more sense to just have separate reload tasks for Cljs and non-Cljs development
there are probably all kinds of unexpected useful tools that can use that to do things for you
but you're right, there should bedifferent specialized tasks for different purposes too
only if someone is already using it and doesn't want to change their things to the new way
I feel strongly that the new implementation is correct and old uses bad practices and is unusable in some cases (CI)
but i spent an hour today with a gem issue that resulted in a shitshow in production that came out of nowhere