Fork me on GitHub
#shadow-cljs
<
2018-09-20
>
thheller05:09:47

@dfcarpenter Cursive has that built-in but there is also https://github.com/kkinnear/zprint

kanwei15:09:03

is there a way to exclude an optional npm dependency that is pulled in via a library? https://github.com/dbushell/Pikaday/issues/718

kanwei15:09:24

pikaday supposedly uses moment optionally but it gets pulled in regardless, there's a hack for webpack but how would I do this in shadow-cljs?

thheller15:09:59

@kanwei you can try :js-options {:resolve {"moment" false}}

kanwei15:09:21

@thheller that didn't work

thheller15:09:56

oh doh. yeah thats broken.

thheller15:09:24

@kanwei should be working properly in 2.6.9.

kanwei16:09:22

nice, thanx

justinlee16:09:11

my code now compiles fine in dev mode, but when i run shadow-cljs run shadow.cljs.build-report app build-report.html i get a spec error when trying to compile specter

justinlee16:09:19

how do i even go about diagnosing the issue?

thheller16:09:50

post the error and I can maybe suggest something

thheller16:09:27

do you get the error for shadow-cljs release app as well or just be build report?

justinlee16:09:41

actually upgrading from 1.1.0 to 1.1.1 fixed it

justinlee16:09:46

should have tried that first

thheller16:09:40

how do you like specter? I never looked into it much but recently I feel like I've been doing a lot more nested stuff where it supposedly helps?

justinlee16:09:52

I think it is awesome, though I don’t like how big it is, but in reality, I’m writing a very heavyweight app so it doesn’t really matter

justinlee16:09:32

for the front end, I do the standard single-atom state object and have all of my mutators in one place sort of like redux reducers

justinlee16:09:50

each “reducer” is typically a single specter transform

justinlee16:09:04

something like this is where it really shines:

(multi-transform
   [ATOM (multi-path
          [:notebook-order (terminal-val notebook-order)]
          [:notebooks      (terminal #(merge-with into % notebooks))])]
   root)
This replaces one key and merges in with another in a single mutation

justinlee16:09:37

if you have a lot of this kind of stuff it becomes pretty easy to read and is very concise

thheller16:09:22

code like this .. a nested map where I want to remove stuff by some nested key deep down

thheller16:09:17

ideally I'd want to remove some values but also return the values that were removed besides the updated value

thheller16:09:41

kinda looks dirty to have the side effect right in there 😛

justinlee16:09:19

right i’m not 100% sure i follow this code but its the kind of thing that specter is good at

thheller16:09:58

{:repl-sessions {1 {:tool-id 1 ...} 2 {:tool-id 2 ...}}

thheller16:09:06

remove all vals where tool-id = 1

justinlee16:09:16

oh yea it’s great at taht

justinlee16:09:27

i think i have code like that

justinlee16:09:39

I do that by-id transform quite a bit so i have a helper:

(defn by-id [id] (fn [elt] (= (:id elt) id)))
(setval [ATOM :uploads ALL (by-id (:id upload))] upload root)

justinlee16:09:03

i’d have to think about how to do that by-vals transform you’re doing

thheller16:09:04

yeah I guess I'll look into it some more. heard enough interesting things about it by now so it seems to be useful

thheller16:09:31

just how much code does it generate though? not a fan if it adds too much code 😛

justinlee16:09:56

it is a bit complicated, i’ll say, but in my opinion it is harder to write than to read. also nathan is quite responsive in #specter. supposedly it is super fast, thought that doesn’t matter to me so much

justinlee16:09:20

i’ve chatted with nathan about getting the code size down. he said it is definitely possible to pull in less of the library, but he doesn’t do a lot of cljs so hasn’t messed with it. it adds 188k of unzipped code

justinlee16:09:29

the generated code i think should be a fairly tight loop

thheller16:09:27

hmm thats quite a lot

Jeff Friesen16:09:53

I’m trying to autorun tests in cljs files. I’ve used the config in the docs

{...
 :builds
 {:test
  {:target    :node-test
   :output-to "out/node-tests.js"
   :ns-regexp "-spec$"
   :autorun   true}}}
shadow-cljs compile test
The tests run fine:
shadow-cljs - connected to server
[:test] Compiling ...
========= Running Tests =======================

FAIL in (a-failing-test) (cljs-runtime/cljs/test.cljs:476:9)
expected: (= 1 2)
  actual: (not (= 1 2))

Testing test.classify-test

FAIL in (a-failing-test) (cljs-runtime/cljs/test.cljs:476:9)
expected: (= 1 2)
  actual: (not (= 1 2))

Ran 2 tests containing 2 assertions.
1 failures, 0 errors.
===============================================
[:test] Build completed. (27 files, 1 compiled, 0 warnings, 0.99s)
But then the tests quit and don’t watch for changes. What does autorun do? Is there a way to run the tests when either the tests change or the functions they test change? Thanks

thheller16:09:19

shadow-cljs compile test compiles once and exits

thheller16:09:27

shadow-cljs watch test will do what you want

thheller16:09:49

autorun runs the node process to execute the tests

Jeff Friesen16:09:42

Yep - that is working. Thank you

richiardiandrea17:09:16

so I am using bunyan in shadow-cljs and they have a logger object that has a .child method

richiardiandrea17:09:45

what would be that quickest way to provide or infer this extern so that it does not get renamed?

richiardiandrea17:09:58

I see shadow-cljs check complains about it, which is good

richiardiandrea17:09:31

can I just use ^js?

richiardiandrea17:09:35

ah no I can't I am in a macro ...

richiardiandrea17:09:26

ok using this for now:

{:optimizations :advanced
 :variable-renaming :off
 :property-renaming :off
 :source-map true}
no time for fiddling 😄

thheller17:09:19

@richiardiandrea you can use it in a macro just fine. just need to watch how you create the symbol

thheller17:09:49

don't turn renaming off. output is gonna be huge

richiardiandrea17:09:51

@thheller isn't ^js a reader macro? maybe I am mistaken

thheller17:09:06

no it is metadata

richiardiandrea17:09:18

uhm ok, it did not work...

thheller17:09:35

like I said you need to check how you create the symbol

thheller17:09:06

generally (let [the-sym (with-meta (gensym) {:tag 'js})] ...)

richiardiandrea17:09:09

I do:

(defmacro child-logger
  "Create a child logger for the current namespace."
  []
  `(. ^js (deref laputa.event-store.logging/parent-logger)
      (~'child (cljs.core/js-obj
                    :namespace (laputa.event-store.logging/self-ns-name)
                    :level (if ^boolean goog.DEBUG "debug" "info")))))

richiardiandrea17:09:24

that is maybe what is not working

thheller17:09:46

(defmacro child-logger
  "Create a child logger for the current namespace."
  []
  `(.child ^js (deref laputa.event-store.logging/parent-logger)
     (cljs.core/js-obj
       :namespace (laputa.event-store.logging/self-ns-name)
       :level (if ^boolean goog.DEBUG "debug" "info"))))

thheller17:09:53

try this. the . may be loosing the meta

thheller17:09:15

or better yet

richiardiandrea17:09:31

I was trying (let [the-sym (with-meta 'child {:tag 'js})]...

thheller18:09:00

(defmacro child-logger
  "Create a child logger for the current namespace."
  []
  `(laputa.event-store.logging/get-child-logger
     (cljs.core/js-obj
       :namespace (laputa.event-store.logging/self-ns-name)
       :level (if ^boolean goog.DEBUG "debug" "info"))))

thheller18:09:08

eliminates all need for tags in the macro

richiardiandrea18:09:36

let me see and thanks 😄 did not know about that trick above

thheller18:09:47

(defmacro child-logger
  "Create a child logger for the current namespace."
  []
  `(laputa.event-store.logging/get-child-logger
     (laputa.event-store.logging/self-ns-name)
     (if ^boolean goog.DEBUG "debug" "info")))

thheller18:09:57

and get rid of the extra js-obj 😉

👍 4
richiardiandrea19:09:53

@thheller another question, how would you go about not renaming env vars? e.g.: process.env.PGDATABASE

thheller19:09:05

js/process.env.PGDATABASE will never be renamed

richiardiandrea19:09:43

oh ok, I was using process.env.PGDATABASE

richiardiandrea19:09:08

which works at runtime but it is obviously odd...forgot the js/

thheller19:09:29

don't you get a warning for that?

richiardiandrea19:09:44

with check yes, I just checked

richiardiandrea19:09:11

File: /home/arichiardi/git/laputa/event-store/src/laputa/event_store/db/config.cljs:31:19
 Property PGDATABASE never defined on process.env

thheller19:09:51

hmm strange. I would expect a warning for process.env.PGDATABASE

thheller19:09:27

hmm yeah no warning. thats a bug I think.

richiardiandrea19:09:39

ok will open an issue

thheller19:09:57

check with plain CLJS first

thheller19:09:04

dunno if its a bug in shadow-cljs or CLJS

richiardiandrea19:09:32

still getting the warnings with check after js/ was added

thheller19:09:43

hmm I don't?

richiardiandrea20:09:03

Ok well, might be something here ;)

richiardiandrea21:09:29

@thheller do you use a monorepo? if yes do you have a shadow-cljs server started in the monorepo root?

richiardiandrea21:09:41

(is it possible?)

thheller21:09:55

not sure I understand the question. define a monorepo? I have one repo per project? is that a monorepo?

richiardiandrea21:09:35

yep so I have this:

├── cljs-template
├── commit-event-fn
├── continuous-delivery
├── dashboard
├── lerna.json
├── metrics-fn
├── package.json
├── query-events-fn
├── README.md
├── registry-fn
├── scrutinizer-fn
each folder has a shadow-cljs file, I was wondering if I could share the jvm

thheller21:09:32

if you look at the shadow-cljs repo there are quite a few builds now that actually do stuff and aren't just for testing

thheller21:09:42

eg. the ui or cli builds

thheller21:09:56

they output to packages/shadow-cljs for example

richiardiandrea21:09:05

I could probably have a shadow.edn in the root containing all the builds for the subrepos..

thheller21:09:05

so the output itself is isolated

thheller21:09:14

and the sources are in their own namespaces

richiardiandrea21:09:25

will have a look

thheller21:09:00

all their sources are in src/main not in packages/... at all

richiardiandrea21:09:53

yep I see, we have a different folder layout

richiardiandrea21:09:55

that's ok, just wondering, would've been cool useful

thheller21:09:57

I never saw a reason to organize the code that way since it just gets annoyingly hard to share code

thheller21:09:25

but no idea about your project or how you organize it with multiple people

richiardiandrea21:09:36

yeah we moved away from that to make sure we isolate lambda development...

richiardiandrea21:09:03

trying to make sure what we share goes in a lib but has some friction so that it does not become a kitchen sink

thheller21:09:39

we already use namespaces to organize code so for CLJS I see no reason they can't all be on the same source-path

thheller21:09:48

since building the code will only include whatever is used

richiardiandrea21:09:18

I know I know how you feel about that and that's ok in single project, everything is on the classpath, but it was getting messy...

richiardiandrea21:09:26

so the team decided to split

richiardiandrea21:09:33

was not even my own decision per se

thheller21:09:50

yeah I can see that too

richiardiandrea21:09:53

still very happy with shadow-cljs, I could potentially include everyting in a big deps.edn + shadow-cljs.edn at some point...will see

thheller21:09:33

well its just data so if the builds have unique names you can just slurp and merge em all 😉