This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-11-20
Channels
- # babashka (56)
- # beginners (151)
- # calva (3)
- # cider (31)
- # clj-kondo (17)
- # cljs-dev (5)
- # clojure (26)
- # clojure-australia (21)
- # clojure-dev (7)
- # clojure-europe (23)
- # clojure-nl (5)
- # clojure-spec (54)
- # clojure-uk (11)
- # clojuredesign-podcast (8)
- # clojurescript (77)
- # community-development (10)
- # core-typed (1)
- # cursive (3)
- # datomic (7)
- # docker (67)
- # emacs (10)
- # expound (6)
- # figwheel-main (3)
- # graalvm (67)
- # helix (10)
- # java (13)
- # jobs (6)
- # kaocha (4)
- # leiningen (15)
- # malli (2)
- # meander (31)
- # off-topic (40)
- # pedestal (9)
- # rdf (7)
- # reagent (5)
- # reitit (9)
- # remote-jobs (5)
- # shadow-cljs (94)
- # sql (7)
- # testing (12)
- # tools-deps (75)
- # vim (13)
Hi, I am running into TypeError: $jscomp.inherits is not a function
when I am using a third party dependency (helix), one particular macro from it does it. I already tried to update and restart everything, I also added :output-feature-set :es8
to compiler options and I really wish I could do something that's not just guesswork but actual diagnostic and work. Any ideas?
I never know how to easily read version information. I am used to just add --version after cli commands and they print their version
shadow-cljs info
also works but only in limited ways if you use deps.edn or project.clj
i just do a shadow-cljs restart every time i need to start it, so it clear the usually stuck lock file from previous start
it doesn't print anything other than shadow-cljs - config: path/shadow-cljs.edn shadow-cljs - server starting .......................... ready!
you told me to do it this way because i was having trouble managing 3 different terminal outputs. It's much better I admit
well there were several $jscomp
related issues that I fixed recently but they should definitely be fixed in 2.11.7
looks fine except the :output-feature-set :es8
is only in the :release
config. I'm assuming the problem you mentioned appears in watch/compile?
btw this is old and not needed anymore shadow.remote.runtime.cljs.browser
in :preloads
. you can just remove it.
Didn't really wanted to do this, but I need class components because of react. I would avoid using them if I knew how, but ..
I see what you mean by the config only in the release. That would explain it, I will try in a minute, thanks
also in the :release
the :modules
and :output-dir
are exactly the same as outside so you can remove it
I’m assuming it’s known that running shadow-cljs with the latest clojure cli tools appears to print a warning about invoking the clojure cli tools in a (recently) deprecated way: > WARNING: When invoking clojure.main, use -M
$ clojure -Sdescribe
{:version "1.10.1.716"
:config-files ["/usr/local/Cellar/clojure/1.10.1.716/deps.edn" "/Users/rick/.clojure/deps.edn" ]
:config-user "/Users/rick/.clojure/deps.edn"
:config-project "deps.edn"
:install-dir "/usr/local/Cellar/clojure/1.10.1.716"
:config-dir "/Users/rick/.clojure"
:cache-dir "/Users/rick/.clojure/.cpcache"
:force false
:repro false
:main-aliases ""
:repl-aliases ""}
ok I think the change is basically you now need to invoke clojure.main
with clojure -M -m clojure.main
well does that work with older versions? if not then I'm not changing that for a while
probably not
sorry yeah you’ll need clojure -M -m shadow.cljs.devtools.cli ...
A lot
The main thing is the new :exec-fn
and :exec-args
stuff; which is pretty awesome actually… It could be interesting thinking about what it might mean for shadow-cljs…
Though I imagine it’s a lot easier to just carry on with shadow-cljs.edn
as it is 🙂
either way though it may open up some new options for you
yeah I'm not going to enforce using deps.edn on anyone. I don't use it on a single project of mine either.
I certainly know what you mean… it’ll be interesting to see what happens with tools.build
but the :exec-fn
stuff at least now provides a way to integrate tooling to build a library and deploy it
it’s not yet as easy as it should be… but it would be pretty straightforward to make it as easy as lein
to do this bit.
sure. if that some day is less than a 5 lines project.clj
+ lein deploy clojars
I might support it 😉
not less than yet… but it could at least now be made more or less equivalent. I currently have it down to about 30 lines of deps.edn with maybe 4 lines of bash: https://github.com/RickMoynihan/pom-update/blob/37d7bdb0eceb69af0f4796f4b9e7334db3f364a2/deps.edn#L13-L39
IKR… if these libs were integrated together (I’ve done it already in a proprietary project which has slightly more bespoke needs - it could be done as easily as with lein)
give or take a few LOCs
yeah its interesting to see work in this area but so far everything looks kinda clunky
It’s definitely clunky — but :exec-fn
makes things much better and feels like it could well be a decent foundation for new tooling
but good thing is I don't have to do anything. everyone can already use it if they want
https://code.thheller.com/blog/shadow-cljs/2017/11/18/the-many-ways-to-use-shadow-cljs.html
still relevant and also still accurate describing why it won't use :exec-fn
anytime soon
Yeah I definitely agree with your stance in that article… but I think :exec-fn
is still relevant for shadow-cljs.
i.e. if the shadow-cljs api defines entry point tooling functions to just be a single map of data, then they can work with :exec-fn
, so users have more options for integration.
So shadow won’t need to mandate tools.deps
and :exec-fn
; but it could still be an option for users. Providing perhaps a few reasonable constraints are maintained
Anyway, as always thank you for your time 🙇 Shall I create a GH issue about the warning for you, just so there’s a record of it?
Regarding character encoding in the repl. I'm connections via repl to a react-native app running on device:
lein repl :connect 9876
Connecting to nREPL at 127.0.0.1:9876
REPL-y 0.4.4, nREPL 0.7.0
Clojure 1.10.1
OpenJDK 64-Bit Server VM 1.8.0_265-bre_2020_10_20_12_24-b00
...
shadow.user=> (println "Smørrebrød")
Smørrebrød
nil
shadow.user=> (shadow/repl :app)
To quit, type: :cljs/quit
[:selected :app]
cljs.user=> (println "Smørrebrød")
Sm??rrebr??d
nil
In the "Java REPL" encoding is okay, in the "JS REPL" it is broken... any ideas on how to fix that?For me it looks like the JavaScript environment on device uses a different character encoding.
It's a little strange that the JVM "runs" on US-ASCII
lein repl :connect 9876
shadow.user=> (System/getProperty "file.encoding")
"US-ASCII"
despite the fact that -Dfile.encoding=UTF-8
is in the arguments of the java process of lein
?So I suspect I should have the same char encoding in the Java world than in the JavaScript world running on device.
Okay, thanks, cool. Setting :jvm-opts ["-Dfile.encoding=UTF8"]
in shadow-cljs.edn
fixed the problem.
Why is it US-ASCII
bei default? When I launch clj
I get:
% clj
Clojure 1.10.1
user=> (System/getProperty "file.encoding")
"UTF-8"
how can I depend on a local built jar (path to jar) ?
I'm working to patch https://github.com/titonbarua/shadow-cljs-gjs-target/pull/2 to allow for Gnome Extension to be built.
I need to make [[titonbarua/shadow-cljs-gjs-target "0.1.0"] -> [[ shadow-cljs-gjs-target "0.2.0-gnome-extension-patch"]]
I can build the patch locally
@eugen.stan you can run lein install
to install it locally
or in the examples :source-paths
you can just direclty include the code via "../../src"
and no :dependencies
including source-paths in shadow-clj.edn of example/gnome-extension.. project does not work (it will not pull the dependencies of that one)
https://github.com/titonbarua/shadow-cljs-gjs-target/blob/master/project.clj#L6 but it doesn't have dependencies?