This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-01
Channels
- # 100-days-of-code (5)
- # adventofcode (234)
- # aleph (13)
- # announcements (2)
- # architecture (3)
- # bangalore-clj (1)
- # beginners (312)
- # calva (7)
- # cider (6)
- # cljdoc (3)
- # cljs-dev (30)
- # cljsrn (2)
- # clojure (40)
- # clojure-austin (2)
- # clojure-dev (65)
- # clojure-greece (1)
- # clojure-italy (29)
- # clojure-kc (1)
- # clojure-russia (2)
- # clojure-uk (26)
- # clojurebridge (1)
- # clojurescript (4)
- # cursive (11)
- # data-science (1)
- # datomic (43)
- # docker (1)
- # duct (7)
- # emacs (3)
- # figwheel-main (7)
- # fulcro (8)
- # garden (3)
- # graphql (8)
- # hyperfiddle (4)
- # off-topic (10)
- # other-languages (12)
- # pathom (4)
- # portkey (1)
- # remote-jobs (3)
- # rum (8)
- # shadow-cljs (40)
- # tools-deps (68)
- # unrepl (2)
- # vim (5)
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))
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] },
Split is a function in my namespace; gc (and most of the rest of the object) is garbage
can this warning safely be ignored? https://github.com/nathanmarz/specter/issues/267
@vigilancetech well it is definitely a bug but apparently it seems to work ok regardless
@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
typically you want to return #js {:foo my-lib.core/foo :bar my-lib.core/bar :baz some.ns/baz}
and so on
otherwise you can just run with` :compiler-options {:optimizations :simple}` as the :advanced
optimizations are not that relevant on node
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:
Would a dynamically generated map work as an export? Or is it more of a static analysis kind of thing?
you could use :npm-module
instead since that controls what is exported directly in the ns
Ah, that's good to know, I definitely want DCE (my library will be used on node and in browser)
well DCE for libraries isn't all that useful since everything you export will not be removed
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
Does it help with dependencies though? Like including only parts of a cljs utility library
Alright, I'll fiddle with some npm-module stuff, that sounds way nicer. I may submit a PR to the docs too
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.
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?
@thheller FYI I wasn't getting that warning/bug before I upgraded shadow as per our discussion above
@thheller, well I can tell you that my app no longer in fact works since that warning.
@vigilancetech the warning has no impact on the code that was generated at all so it must be something else
@thheller oh great 😕