This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-18
Channels
- # adventofcode (62)
- # aws (5)
- # beginners (59)
- # calva (63)
- # cider (26)
- # cljdoc (1)
- # cljsrn (22)
- # clojure (99)
- # clojure-austin (1)
- # clojure-dev (19)
- # clojure-europe (4)
- # clojure-hamburg (2)
- # clojure-italy (3)
- # clojure-nl (23)
- # clojure-spec (2)
- # clojure-uk (85)
- # clojurescript (41)
- # core-async (17)
- # cursive (20)
- # data-science (11)
- # datascript (2)
- # datomic (31)
- # emacs (7)
- # figwheel (28)
- # figwheel-main (12)
- # graphql (2)
- # hyperfiddle (3)
- # juxt (1)
- # kaocha (2)
- # leiningen (5)
- # nrepl (13)
- # off-topic (45)
- # pathom (13)
- # pedestal (11)
- # re-frame (20)
- # reagent (10)
- # shadow-cljs (92)
- # spacemacs (9)
- # sql (39)
- # tools-deps (32)
- # unrepl (3)
Habe you tried this with expo? I'm curious wether the same bridge could be used for both types of projects :face_with_monocle:
Currently the expo template has some very specific modifications to make it work with the bridge
True, looked at our project.clj and we just compile cljs normally. So I guess that part could easily be migrated to deps.edn as well.
Ok, nevermind. Looked at it again and realized it’s only the figwheel-bridge.js that can be included as an npm dep.
So we can still keep our old workflow, just replace the fighweel-bridge file with this dependency
Interesting stuff
@bhauman do you think it's a logical successor which could replace the re-natal figwheel-bridge? e.g. only makes things better