This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-26
Channels
- # adventofcode (2)
- # beginners (69)
- # boot (37)
- # cider (6)
- # clara (31)
- # cljs-dev (75)
- # cljsrn (5)
- # clojure (72)
- # clojure-dev (7)
- # clojure-italy (11)
- # clojure-nl (8)
- # clojure-russia (2)
- # clojure-spec (56)
- # clojure-uk (54)
- # clojure-za (1)
- # clojurescript (156)
- # cursive (2)
- # datomic (34)
- # emacs (1)
- # fulcro (227)
- # hoplon (74)
- # jobs (1)
- # jobs-discuss (16)
- # leiningen (5)
- # lumo (17)
- # off-topic (9)
- # om (3)
- # onyx (10)
- # other-languages (1)
- # portkey (2)
- # re-frame (2)
- # reagent (36)
- # reitit (1)
- # remote-jobs (1)
- # ring-swagger (8)
- # shadow-cljs (85)
- # slack-help (2)
- # spacemacs (6)
- # specter (3)
- # sql (17)
- # test-check (15)
- # tools-deps (80)
HI all, I’m having trouble making the :node-library target work with the shadow CLI tool installed via npm i.e. not via a lein REPL
The required namespace "pages.handlers" is not available, it was required by "shadow/umd_helper.cljs".
and it works ok when using lein to manage classpath i.e. server and build/watch commands invoked in REPL
@lilactown exclusions are just the symols without versions. thats what it complains about. will add a spec for that.
only other possible mistake is `:exports {:home pages.handlers/home-page :context pages.handlers/app-context-page}`
and what does shadow-cljs browser-repl
then (require '[pages.handlers :as x])
give you? without lein
?
`{;:lein true ; let lein/project.clj manage source-paths and deps :dependencies [] :builds {:pages {:target :node-library :source-paths [“src”] :js-options {:js-provider :shadow} ; include deps in single resource :output-to “out/pages/handlers.js” ; where does compilation output go :exports {:home pages.handlers/home-page :context pages.handlers/app-context-page} :release {:output-to “out/release/handlers.js”}} :test {:target :node-test :source-paths [“src” “test”] :output-to “out/tests/node-tests.js” :ns-regexp “-spec$” :autorun true}}} `
:js-options {:js-provider :shadow} ; include deps in single resource
this doesn't work for node
that was going to be my next question. I’m hoping for a way to generate 1 big js artifact for node. this is destined for AWS lambda
since you are here. the webpack workaround for the single file bundle. is there an example of that somewhere?
FYI : this is for a sample project using Datomic Ion so might get a little more support for shadow once we have it working
I have not used any of the cloud stuff. all my projects are too small to justify cloud stuff. I'm open to adding support for it just don't have the time to look into it currently.
it is definitely possible to do one-file but needs some special treatment since everything is currently meant for the browser
and some of the node emulation stuff needs to be adjusted to not emulate but rather use the real thing
one day I'll go to a conference 😉 they are usually too far away and I hate travelling
I’ve created a small PR for an issue with watch*
- https://github.com/thheller/shadow-cljs/pull/326 - it is currently throwing away the config map it is passed, re-reading the config from its build-id.
@mhuebert oops. the if check should just be removed since it always expects a build-config map. passing a keyword would break the destructure above
I know this is very side effecty but I can't seem to run this in my clj-run
(map #(spit (str % ".txt") "test") ["one" "two"])
I probably need a recursive function but I'm still curious why it doesn't run but the spit on it's own works and doing this function in a repl works as well.
@grounded_sage clj-run
is for calling fully qualified functions, ie. your.thing/foo
if you are doing that inside your function then note that map
is lazy and doesnt do anything unless consumed (wrap in doall
or use doseq
)
Can the :node-test
target be made to generate tests from the :test
functions inside function attribute maps?
@pez maybe? it currently relies in cljs.test/deftest
but since cljs.test
doesn't look for anything besides that the change would really need to be in cljs.test
whats wrong with deftest
? having lots of metadata on defns makes them sort of unreadable no?
and all your namespaces need to import cljs.test
for the is
assertions? it is generally best practice to have separate your.thing
and your.thing-test
namespaces
I think it is very readable to have the tests embedded in the function tested. I like to “document” my functions that way.
I have decided not to use CLJC for the ClojureScript parts of my extensions. It makes it a bit less easy to access the node ecosystem. But at the same time cuts me out of my embedded tests. I was hoping I could eat the cake and have it. 😃
This might be a silly example, but I think it is readable:
(defn- split
"Splits text at idx"
{:test (fn []
(is= [" " " "]
(split " " 1))
(is= ["(foo\n " "\n bar)"]
(split "(foo\n \n bar)" 6)))}
[text idx]
[(subs text 0 idx) (subs text idx)])
It helps me use the REPL to create the function TDD-style. And then I can leave some of the “exploration” code as unit tests where they help both with testing and explaining what the function does.