Fork me on GitHub
#shadow-cljs
<
2018-12-01
>
jstaab00:12:34

Hey there, can anyone tell me how to avoid name mangling using the node-library target? Here's my shadow-cljs.edn:

{:source-paths ["src"]
 :builds
 {:my-lib
  {:target :node-library
   :output-to "lib/my-lib.js"
   :exports-fn my-lib.js/generate-exports}}}
And my file:
(ns my-lib.js
  (:require [my-lib.core]))

(defn generate-exports []
  (clj->js my-lib.core))

jstaab00:12:29

The file contains all the usual stuff, but what's weird is some functions get mangled and some don't for no apparent reason; they're defined the same way, but when I import them from nodejs, I get stuff like:

split: { [Function: d] A: [Function: c], a: [Function: b] },
     gc: { [Function: d] A: [Function: c], a: [Function: b] },

jstaab00:12:41

Split is a function in my namespace; gc (and most of the rest of the object) is garbage

thheller08:12:46

@vigilancetech well it is definitely a bug but apparently it seems to work ok regardless

👍 1
thheller08:12:59

otherwise more people would run into issues I guess

thheller08:12:37

@jstaab typically you want the exports to be static to prevent such renaming. it also is not exactly valid to call (clj->js some.ns) as that will all be renamed

thheller09:12:17

typically you want to return #js {:foo my-lib.core/foo :bar my-lib.core/bar :baz some.ns/baz} and so on

thheller09:12:25

that ensures that the names do NOT get mangled

thheller09:12:00

otherwise you can just run with` :compiler-options {:optimizations :simple}` as the :advanced optimizations are not that relevant on node

jstaab15:12:09

Thanks @thheller I'll give that a try. I was hoping to do something dynamic since I have lots of exports and don't want to enumerate them all. I can just see myself adding a function, testing, building, releasing, integrating into client code then face palming because I forgot to export it :face_palm:

thheller16:12:11

we gotta be explicit about exports otherwise DCE doesn't work 😉

thheller16:12:29

same as JS these days

jstaab16:12:00

What does DCE stand for? Anywhere I can read more about it?

jstaab16:12:21

Would a dynamically generated map work as an export? Or is it more of a static analysis kind of thing?

thheller16:12:23

dead code elimination

thheller16:12:10

dynamic basically means we can't remove anything because it might be used

thheller16:12:02

you could use :npm-module instead since that controls what is exported directly in the ns

thheller16:12:10

(defn ^:export foo [])

jstaab16:12:30

Ah, that's good to know, I definitely want DCE (my library will be used on node and in browser)

thheller16:12:02

well DCE for libraries isn't all that useful since everything you export will not be removed

jstaab16:12:11

Is that in the docs? I don't see anything about not being able to to DCE, or name mangling here: https://shadow-cljs.github.io/docs/UsersGuide.html#_dynamic_exports

thheller16:12:13

even thought the user may only use 2 of the 10 things you export

jstaab16:12:36

Does it help with dependencies though? Like including only parts of a cljs utility library

thheller16:12:08

yeah it is still required for the CLJS parts. otherwise the code will be huge.

jstaab17:12:55

Alright, I'll fiddle with some npm-module stuff, that sounds way nicer. I may submit a PR to the docs too

jstaab17:12:41

Ok, function exports are working great now, is there any way to prevent name mangling of nested object properties? Also, where's the repo for https://shadow-cljs.github.io/docs/UsersGuide.html ? I was thinking of adding a bit of clarification for posterity.

jstaab17:12:35

Oh, oh I didn't clj->js the export

jstaab17:12:33

Another question: is there a way to automatically wrap exported cljs code for js interop? so clj->js on exports and return values; js->clj on function parameters?

jstaab17:12:57

By the way, thanks @thheller for an amazing library and a slice of your saturday 🙂

jstaab17:12:09

Or wait... late Friday?

jstaab17:12:22

Ah, late Saturday, sure

vigilancetech17:12:05

@thheller FYI I wasn't getting that warning/bug before I upgraded shadow as per our discussion above

vigilancetech17:12:27

@thheller, well I can tell you that my app no longer in fact works since that warning.

thheller20:12:19

@jstaab no there is no automation for that but you could do it via a macro

👍 1
thheller20:12:03

@vigilancetech the warning has no impact on the code that was generated at all so it must be something else

thheller20:12:06

what is the issue?

thheller20:12:51

might be the move from CLJS 1.10.339 -> 1.10.439 but I'm not aware of any regressions regarding actual runtime stuff