This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-08
Channels
- # aleph (1)
- # architecture (4)
- # aws (5)
- # beginners (105)
- # boot (1)
- # boot-dev (72)
- # cider (5)
- # clara (15)
- # cljs-dev (51)
- # cljsrn (5)
- # clojure (155)
- # clojure-austin (3)
- # clojure-dusseldorf (2)
- # clojure-finland (1)
- # clojure-greece (37)
- # clojure-italy (17)
- # clojure-nl (1)
- # clojure-russia (6)
- # clojure-spec (23)
- # clojure-uk (6)
- # clojurescript (7)
- # community-development (1)
- # css (10)
- # cursive (15)
- # datomic (45)
- # defnpodcast (1)
- # duct (97)
- # emacs (5)
- # fulcro (46)
- # hoplon (8)
- # instaparse (25)
- # keechma (11)
- # leiningen (16)
- # off-topic (2)
- # onyx (9)
- # planck (2)
- # re-frame (5)
- # reagent (3)
- # reitit (2)
- # ring (6)
- # shadow-cljs (35)
- # spacemacs (9)
- # specter (9)
- # sql (18)
- # uncomplicate (4)
Hey @thheller - as mentioned in #clojurescript, I see the following issue when trying to use shadow-cljs (clojure 1.9.0, clojurescript 1.9.946 and core.async 0.3.443):
Only started using shadow-cljs yesterday and clojurescript a week ago, so bear with me!
[:app] Build failure: ------ ERROR ------------------------------------------------------------------- File: jar:file:/home/alex/.m2/repository/thheller/shadow-cljs/2.0.128/shadow-cljs-2.0.128.jar!/shadow/cljs/devtools/client/hud.cljs:1:1 -------------------------------------------------------------------------------- 1 | (ns shadow.cljs.devtools.client.hud -------^------------------------------------------------------------------------ Invalid :refer, var cljs.core.async/go does not exist -------------------------------------------------------------------------------- 2 | (:require [shadow.dom :as dom] 3 | [shadow.xhr :as xhr] 4 | [shadow.cljs.devtools.client.env :as env] 5 | [shadow.cljs.devtools.client.browser :as browser] --------------------------------------------------------------------------------
so far I'm mightily impressed with shadowcljs; it got rid of all my funky issues that I was having with lein-figwheel when loading (many) npm modules
since the closure compiler's module resolution doesn't support wildcard import/export and a few other things that npm modules do sometimes
whilst on it, though, I have one more question; in lein-figwheel, I used to have a :external-config {:devtools/config {:features-to-install [:formatters :hints]}}
to configure binaryage/devtools
I think you can stick that in :compiler-options
, so :compiler-options {:external-config {:devtools/config {:features-to-install [:formatters :hints]}}}
I see that shadow-cljs's manifest.edn is very similar to manifest.json for a chrome plugin I'm about to start to develop. I wonder if there's any trick for shadow to output manifest.json or rewrite the manifest.json on changes. I see myself manually adding js path to new files as I add namespaces and libraries. But this just gave me the idea that this should be possible.
(given that this is not a problem with optimized compilations as they output 1 file, but at cost of long time)
@hlolli you can specify :manifest-name "manifest.json"
. the output format is chosen by file ext, just defaults to manifest.edn
its just some information about your modules in case you want to use :module-hash-names
and need to get the actual filenames (since they are hashed)
thats the code that generates the manifest. should be easy to extend/modify based on your needs
ok ok, my brain is uncaffinated and slow. Yes I'll check it out. Should manifest-name be located top-level in shadow-cljs.edn?