@mhuebert I decided against putting the externs into the config because it might make the config “big”. I can allow it there as well though.

ideally there would be some sort of “library” where externs for packages are collected

something like cljsjs has done

I just don’t want to maintain that

but something that maps npm packages names to their externs

https://twitter.com/thheller/status/919547437479493632

wrote that thing about externs

https://www.reddit.com/r/Clojure/comments/76isfz/cljs_externs_the_bane_of_every_release_build/

Resending messages failed while hiking...

for file format, what about sth like an .edn file of {:globals [...] :properties [...]}?

that can be referenced by any # of builds

Am wondering about reuse across builds, and inclusion in libraries

Eg. I have a keyboard commands library that uses a JS lib, could I somehow include an externs file (txt or edn) that use picked up by downstream users?

didn’t choose edn since that seems like too much to write

just one identifier per line is enough, don’t need all the edn literals

but yeah sharing across builds and libraries needs to happen somehow

you can as always use the deps.cljs to ship :externs but that only works for the “real” externs. not the simplified version.

can’t use the simplified version in libraries unless CLJS adopts it so it works for tools besides shadow-cljs

Yeah, good point. Libraries can use the normal syntax