Yes

@thheller: I wrote a blog post about https://ghufran.posthaven.com/using-devcards-with-shadow-cljs. 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

(ns 
  (:require
   [devcards.core :as dc])
  (:require-macros
   [devcards.core :refer [defcard]]))

this is enough

(ns 
  (:require
    [devcards.core :as dc :refer [defcard]]))

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

> (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 miracle.save, 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

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

(syntax highlighting would be the correct word)

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

@neo2551 colorzing what exactly?

The data structure litterals that are in the pretty print windows

or even the inspector?

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

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

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

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 😛

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

with shadow-cljs

hmm?

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

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

oh okay nevermind

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

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

what about just for pretty-print/edn?

I don't use browser that much

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

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

@neo2551 https://github.com/thheller/shadow-cljs/commit/0f9d9a0d034cddc5dece731526f0b9cedd879554 I'll probably make a release later

Thanks!

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

--config-merge in general

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 😕

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

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 https://www.npmjs.com/package/@date-io/date-fns/v/1.3.13 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",

> require('@date-io/date-fns')
[Function: DateFnsUtils]

(require '["@date-io/date-fns" :as d1])
cljs.user=> d1
#object[DateFnsUtils]

(:require
;; 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 also see the following in the compiled file for the npm-module build: shadow.js.shim.module\$\$date_io\$date_fns.js

goog.provide("shadow.js.shim.module$$date_io$date_fns");
goog.provide("module$shadow_js_shim_module$$date_io$date_fns");
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;

@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

Found:

:js-options {:js-provider :require}

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

Yep!

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

https://github.com/shadow-cljs/shadow-cljs.github.io happy about a PR though 😛

Cool, I'll see what I can write up