Fork me on GitHub

@thheller: I wrote a blog post about I ran into some strange behavior, where changing the order of the (:require ..) vectors in the ns declaration seemed to lead to errors - can you take a look when you get a chance and let me know of any errors / omissions? Thanks!


@ghufran you do not need this complex ns require

   [devcards.core :as dc])
   [devcards.core :refer [defcard]]))


this is enough

    [devcards.core :as dc :refer [defcard]]))


you also do not need [thheller/shadow-cljsjs "0.0.21"]. just need to install marked.


Interesting - so is the functionality that used to be in shadow-cljsjs now incorporated into shadow-cljs?


shadow-cljsjs has always been a dependency of shadow-cljs and you never need to require it directly. you never did so I don't know what made you think you need the require. would be curious to know what made you think that?


When I read the, I assumed from the name that it was for use with shadow-cljs - probably because I found it from this, where it seemed a shim file was needed, and that shadow-cljsjs was a ‘one-stop-shop’ for those shims 🙂. Maybe we could update the shadow-cljsjs repo to make clear it’s not required separately if you are using shadow-cljs?


> (Note: you may need to hit CTRL-C in order to get back to the terminal after this error).


you can also just open another terminal do the install, no need to restart shadow-cljs. it should pick up the newly installed package.


re: ?> et. al. -- sounds interesting 🙂 I've played around a bit in this area with, but I hadn't considered you could get line information. this is only possible in cljs, right? I haven't figured out a way to capture this in clojure

David Pham11:05:20

@thheller Do you think colorizing code in the inspect window of shadow-cljs would be a big work?

David Pham11:05:36

(syntax highlighting would be the correct word)


@saikyun this works for CLJ too. you can get the line/column from the form metadata


huh, really? thanks for the info. this is great news.


@neo2551 colorzing what exactly?

David Pham11:05:07

The data structure litterals that are in the pretty print windows

David Pham11:05:15

or even the inspector?

David Pham11:05:52

If you tap a map, it would be nice to have the string colorized, or the keywords in a different color.

David Pham11:05:20

Maybe we are too spoiled with our IDEs so when I see the data structure on inspect, I wish to have the same visual clues

David Pham11:05:28

but I am already quit thankful for inspect 🙂


not sure what the point of that would be? but I'm also not sure what exactly you are referring too


the "view as pretty-print/edn" could be syntax highlighted yes


the browse view not really

David Pham11:05:48

yes, I was referring to the view as pretty-print/edn


not sure it needs to


I barely ever use those so hasn't been a priority for me 😛

David Pham11:05:17

haha, I am just saying that it is nice since pretty printing does not work on Emacs

David Pham11:05:20

with shadow-cljs


ah the automagic nrepl stuff? just set :devtools {:repl-pprint true} if you want pprint

David Pham11:05:58

Cider never pretty prints my result when I connect to shadow-cljs

David Pham11:05:54

oh okay nevermind

David Pham11:05:59

I learned something today 🙂


I had some ideas for colorizing the browse output a bit. I may do that at some point but its quite a lot of work so may take a while

David Pham11:05:18

what about putting code mirror in it?


thats what I'd do for pretty-print/edn


for browse that is not an option. performance would be horrific

David Pham11:05:00

what about just for pretty-print/edn?

David Pham11:05:10

I don't use browser that much

David Pham11:05:36

It is cool for big inputs, but usually pretty-print

David Pham11:05:00

It is great because it allows to have some history of the print and Emacs is not providing that


Hi everyone, Is there a way in shadow-cljs to pass some values/configuration to the app based on the build target - for instance to set the address for my api requests localhost:3000 for :dev mode and for :release ? Thanks

Andy Heywood14:05:14

--config-merge in general

Andy Heywood14:05:23

I don’t think there are any other options, other than of course different targets which weirdly I didn’t think about when I was doing this 😕

Andy Heywood15:05:33

but if your target has a large proportion of varying data vs static data, maybe that’s a good option


Thanks a lot, Andy


I came across an interesting situation where a js module is required correctly using :as for a browser build, but resolves to nil in an :npm-module build. Additionally, in an :npm-module build :default resolves the package correctly. I'm using this js library I noticed that their package.json (within node_modules/@date-io/date-fns) has this :

{"name": "@date-io/date-fns",
  "version": "1.3.13",
  "description": "Abstraction over common javascript date management libraries",
  "main": "build/index.js",
  "module": "build/index.esm.js",
I'm not sure if that module entry is what's messing things up. at a plain node repl:
> require('@date-io/date-fns')
[Function: DateFnsUtils]
it doesn't come in as an object with default on it - which is the desired behavior and is what happens in the :browser build. this is confirmed in a shadow browser-repl also:
(require '["@date-io/date-fns" :as d1])
cljs.user=> d1
anyway. I got things working by doing this:
;; for browser target
 ["@date-io/date-fns" :as date-fns]
;; for npm-module target
 ["@date-io/date-fns" :default date-fns2])

(def date-util-fn (or date-fns2 date-fns))
I'm not sure what is causing the difference, but posting here in case someone knows or has run into this.


I also see the following in the compiled file for the npm-module build: shadow.js.shim.module\$\$date_io\$date_fns.js

shadow.js.shim.module$$date_io$date_fns = require("@date-io/date-fns");
module$shadow_js_shim_module$$date_io$date_fns.default = shadow.js.shim.module$$date_io$date_fns;


Interesting - so is the functionality that used to be in shadow-cljsjs now incorporated into shadow-cljs?


@danvingo it depends on the tool you use to fulfill the require("@date-io/date-fns");. it probably defaults to using the module entry whereas shadow-cljs and node default to using main


its one of my favorite subjects ... commonjs<->esm interop ... its ugly ...


nothing shadow-cljs can do really since it doesn't process the require


when it does (eg. :browser) I have some limited control which is why it defaults to main still since modules only really works if every package you use supports it


thanks for the feedback @thheller it's being processed as part of webpack so that would explain it


i'm fine with the solution to just check which one is resolved


Is there a way to have :target :browser but be able to access NodeJS APIs like fs? My use case is the renderer process in an electron app



:js-options {:js-provider :require}
Will this still bundle things up? Do I need to bundle things up in an electron app? I'll research this, but if anyone knows, holler!


I don't know what the best practice for electron. :require will not bundle anything no.


Okay, good to know, thanks. My guess is it's still valuable for app updates


@thheller Would there be a way now or in the future to whitelist which imports to use with the runtime require vs. shadow-cljs? I feel like that would be the sweet spot for Electron


@mruzekw not sure what you mean?


do you have 2 builds or just one? been a while since I looked at electron stuff


there is :js-options {:keep-as-require #{"foo" "bar"}} which wouldn't bundle those if you mean that

👍 4

So if I just needed fs to be from the encompassing runtime, it would keep it as require


you can set :js-options {:keep-native-requires true}


that keeps all the node-builtins as require including fs


Nice! That's all I would really need


I'll try that out now


Works great! Thank you! Would be good to have that in the docs. I could help create an Electron section


I haven't look at any electron stuff in a long long time so I don't feel qualified to write about it


Cool, I'll see what I can write up