Fork me on GitHub
#shadow-cljs
<
2020-05-25
>
ghufran05:05:53

@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!

thheller07:05:54

@ghufran you do not need this complex ns require

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

thheller07:05:17

this is enough

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

thheller07:05:45

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

ghufran17:05:35

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

thheller17:05:16

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?

ghufran17:05:40

When I read the https://github.com/thheller/shadow-cljsjs, I assumed from the name that it was for use with shadow-cljs - probably because I found it from this https://github.com/bhauman/devcards/issues/156, 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?

thheller07:05:07

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

thheller07:05:29

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

Saikyun10:05:09

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

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)

thheller11:05:27

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

Saikyun16:05:36

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

thheller11:05:41

@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 🙂

thheller11:05:58

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

thheller11:05:10

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

thheller11:05:27

the browse view not really

David Pham11:05:48

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

thheller11:05:52

not sure it needs to

thheller11:05:36

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

thheller11:05:50

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 🙂

thheller11:05:03

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?

thheller11:05:33

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

thheller11:05:46

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

Ho0man14:05:26

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

Ho0man15:05:54

Thanks a lot, Andy

dvingo17:05:39

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",
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
#object[DateFnsUtils]
anyway. I got things working by doing this:
(: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'm not sure what is causing the difference, but posting here in case someone knows or has run into this.

dvingo17:05:17

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;

ghufran17:05:35

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

thheller17:05:37

@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

thheller17:05:12

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

thheller17:05:33

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

thheller17:05:16

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

dvingo17:05:25

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

dvingo17:05:55

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

mruzekw18:05:27

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

mruzekw19:05:39

Found:

: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!

thheller19:05:56

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

mruzekw19:05:49

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

mruzekw20:05:02

@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

thheller20:05:04

@mruzekw not sure what you mean?

thheller20:05:34

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

thheller21:05:07

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

👍 4
mruzekw21:05:19

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

thheller21:05:11

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

thheller21:05:36

that keeps all the node-builtins as require including fs

mruzekw21:05:02

Nice! That's all I would really need

mruzekw21:05:06

I'll try that out now

mruzekw21:05:37

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

thheller21:05:49

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

mruzekw21:05:23

Cool, I'll see what I can write up