This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-04
Channels
- # announcements (3)
- # babashka (14)
- # beginners (151)
- # calva (14)
- # cider (9)
- # clj-kondo (24)
- # cljdoc (12)
- # cljs-dev (195)
- # cljsjs (3)
- # cljsrn (13)
- # clojars (12)
- # clojure (234)
- # clojure-dev (3)
- # clojure-europe (9)
- # clojure-greece (1)
- # clojure-italy (2)
- # clojure-japan (4)
- # clojure-nl (4)
- # clojure-spec (89)
- # clojure-taiwan (1)
- # clojure-uk (16)
- # clojuredesign-podcast (2)
- # clojurescript (17)
- # conjure (11)
- # core-async (4)
- # core-typed (31)
- # cursive (9)
- # datomic (8)
- # emacs (17)
- # figwheel (1)
- # fulcro (5)
- # ghostwheel (42)
- # graphql (3)
- # hugsql (5)
- # jackdaw (3)
- # jobs-discuss (93)
- # joker (4)
- # meander (6)
- # mount (1)
- # off-topic (23)
- # pathom (10)
- # re-frame (23)
- # reitit (7)
- # remote-jobs (18)
- # shadow-cljs (153)
- # spacemacs (24)
- # sql (30)
- # tools-deps (14)
- # vim (12)
- # xtdb (1)
I somewhere read, that shadow-cljs can create statistics on the composition of the size of all the modules that are in a bundle. Can someone tell me how to do that? I am trying to better understand the size implicatios of the different dependencies in my bundle, so that I can possibly split parts of it in a more lazy fashion. Thanks!
Thanks @U1UQEM078
I'm struggling to figure out how to exclude ghostwheel from my release builds with shadow-cljs. The documentation suggests that it's only included if compiler options are set for the :dev
build, but I can see 100kb+ of stuff for ghostwheel and its dependencies in my release build report.
I don't think ghostwheel has any kind of options to remove it completely. you can try https://github.com/fulcrologic/guardrails which ensures think can be eliminated a little better.
Thanks! I'll try that.
you can try setting up something like this https://github.com/day8/re-frame-debux/issues/30
ie. create a stub ns that actually does nothing and also doesn't require any additional dependencies
Oh, right. There appears to be a Github repo with a stub ns for Ghostwheel, but no information about what you're supposed to do with it.
I think I was confused by the documentation for turning off runtime checks in release builds vs. actually stubbing the library out (which is undocumented maybe?)
ah yeah thats the common approach. you basically just replace the ghostwheel dependency on the classpath with the stubs
but that requires changing the classpath for dev/release builds which I think is a bit icky
{:builds
{:app
{:target :browser
...
:release
{:build-options
{:ns-aliases
{ghostwheel.core ghostwheel.core-stubs}}}}}
Aha. I couldn't find a single example of anyone actually doing this on github.
the typical method just uses different dependencies and switching the alias/profile using deps.edn/lein
aliasing the ns is only supported by shadow-cljs and I haven't documented it much so it isn't exactly widely used 😛
Ah, ok. There is a stub library but it has the same namespace as the real one, so presumably I'm meant to switch them. And to do that I need deps.edn and can't do it in shadow-cljs?
The stubs approach with the same namespace in two different artifacts seemed to me like the best way to reliably eliminate all dependencies from the production build at the time. It was inspired by https://github.com/philoskim/debux.
I do however agree with @thheller that it's not a particularly pretty solution, I believe we even had a brief conversation about it at the time. For the next Ghostwheel release I plan to do it with a special version of gnl/ghostwheel rather than a different artifact, so it can be overridden using :override-deps
in deps.edn. Unless, that is, a better and equally reliable approach comes up in the meantime.
Feel free to post in #ghostwheel if anything else comes up.
That makes sense. Thanks!
In general, what can go into the :build-options key?
I did not find anything in the docs
Thanks a lot! I really liked ns-aliases
It saved my ass today for devcards 0.2.7
Is there a way to build code in release mode while triggering new builds whenever a file changes?
@martinklepsch no. I'd recommend triggering the compile from the REPL.
Ok, guess I’ll try to hook that up to a watcher than. For debugging advanced issues this is quite handy
(I’m back to debugging our node source maps issues 😅)
shadow-cljs release app --pseudo-names
while shadow-cljs server
is running is what I typically do
:advanced
builds typically take too long to compile so with a watch you can end up queing another rebuild while the current one is running
yeah I realized that might be an issue
is there a way to restart the server after installing cljs dependences without killing the previous process?
it works with npm dependences, but when i install cljs dependency, I always have to kill the process and restart it
Hi,
Not sure if this is the right place to ask.
I am trying to use a npm library and the import statement is sort of failing.
Library - https://github.com/ruilisi/react-chessground
Relevant code bits:
lein new re-frame test
npm install --save react-chessground
(:require ["react-chessground" :as rcg :default Chessground])
[:> Chessground {}]
Chessground is undefined/nil and (.log js/console rcg) returns an empty object instead of a module.
Tested that the library is working with this example from readme.
https://github.com/ruilisi/react-chessground/tree/master/example
@thheller There is one reference issue.
app.js:2231 An error occurred when loading benoni.components.chess_ground.js
env.evalLoad @ app.js:2231
app.js:2232 ReferenceError: $jscomp is not defined
at Object.shadow$provide.module$node_modules$chessground$util (:8280/js/compiled/cljs-runtime/module$node_modules$chessground$util.js:1)
at shadow.js.jsRequire (js.js:66)
at Object.shadow$provide.module$node_modules$chessground$board (:8280/js/compiled/cljs-runtime/module$node_modules$chessground$board.js:8)
at shadow.js.jsRequire (js.js:66)
at Object.shadow$provide.module$node_modules$chessground$api (:8280/js/compiled/cljs-runtime/module$node_modules$chessground$api.js:1)
at shadow.js.jsRequire (js.js:66)
at Object.shadow$provide.module$node_modules$chessground$chessground (:8280/js/compiled/cljs-runtime/module$node_modules$chessground$chessground.js:1)
at shadow.js.jsRequire (js.js:66)
at Object.shadow$provide.module$node_modules$react_chessground$chessground (:8280/js/compiled/cljs-runtime/module$node_modules$react_chessground$chessground.js:2)
at shadow.js.jsRequire (js.js:66)
shadow-cljs version is 2.9.3
.
The reference error is happening only when this particular library is loaded.
@thheller Tested it with 2.9.10
. Still facing the same issue. (upgraded version - lein deps - lein run)
don't have time to look at it closer now but you can maybe fix the issue by setting :compiler-options {:output-feature-set :es6}
$jscomp
issues should be fixed but I don't know enough about your setup to comment further
@thheller After adding :compiler-options {:output-feature-set :es6}
the reference error disappeared. Able to use the library now.Thanks.
Hi, I already have running shadow-cljs watch app
in terminal, and I'm already connected to repl (under user namespace) using intellij cursive (see screenshot for the config).
When I run (shadow/repl :app)
I'm getting this message No such var: shadow/repl
What am I missing here?
otherwise it depends on which namespace you are in and only works in shadow.user
by default.
Even when I switch to that namespace, its not working (see screenshot). Here is my shadow-cljs.edn
{:deps {:aliases [:web]}
:builds
{:app {:target :browser
:output-dir "resources/public/app"
:asset-path "/"
:modules {:app {:init-fn limeray.web.core/init}}
:devtools {:http-port 9000
:http-root "resources/public/app"
:preloads [devtools.preload]}}}}
THis is the alias entry in deps.edn
:web {:extra-deps {thheller/shadow-cljs {:mvn/version "2.8.94"}
thheller/shadow-cljsjs {:mvn/version "0.0.21"}
tick {:mvn/version "0.4.17-alpha"}
org.clojure/clojurescript {:mvn/version "1.10.597"}
reagent {:mvn/version "0.9.1"}
metosin/reitit {:mvn/version "0.4.2"}
binaryage/devtools {:mvn/version "1.0.0"}
cljs-bean {:mvn/version "1.5.0"}
cljs-http {:mvn/version "0.1.46"}
devcards {:mvn/version "0.2.6"}}}
oh ok. I was thinking shadow-cljs creates nrepl.port file? I created symbolic link to point to it
â–¶ readlink .nrepl-port
webapp/.shadow-cljs/nrepl.port
I should put readme file on this project. I always get stuck like an hour before I figure out how to connect to repl 😆
cursive in EAP supports looking at the .shadow-cljs/nrepl.port
file directly so that gets a bit easier 🙂
Hello
I'm trying to build shadow-cljs
for complex debug purposes, having customized Google Closure Compiler. I've built Google Closure Compiler's v20200504
with mvn -DskipTests -pl externs/pom.xml,pom-main.xml,pom-main-shaded.xml
and referenced it from project.clj
, replacing v20200504
with 1.0-SNAPSHOT
. When running ./build-cli.sh
I'm having this error:
Compiling 17 source files to /home/andrey/Work/se/shadow-cljs/target/classes
warning: [options] bootstrap class path not set in conjunction with -source 8
/home/andrey/Work/se/shadow-cljs/src/main/com/google/javascript/jscomp/ShadowAccess.java:62: error: cannot find symbol
public static final DiagnosticType NON_GLOBAL_DEFINE_INIT_ERROR = ProcessDefines.NON_GLOBAL_DEFINE_INIT_ERROR;
^
symbol: variable NON_GLOBAL_DEFINE_INIT_ERROR
location: class ProcessDefines
Note: /home/andrey/Work/se/shadow-cljs/src/main/shadow/undertow/ShadowResourceHandler.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
1 warning
Compilation of Java sources(lein javac) failed.
Note: I'm using java-11-openjdk-amd64
ah so is this shadow-cljs/src/main/com/google/javascript/jscomp/ShadowAccess.java
actually taken from GCC?
ah. true
that class is in the shadow-cljs repo because it accesses a bunch of package-protected stuff shadow-cljs can't otherwise access
I've actually compared (using vim as archive viewer, haha) two jars — and my SNAPSHOT
one differs from the v20200504
. Though I've built it off of v20200504
tag branch
aha...
faster for me to just access this stuff directly to fix certain annoyances rather than going for a github issue and waiting 2 years 😛
or Google Groups? 🙂
btw you're right. I've messed the jars a little bit, needed to specify the exact one I need to compile
they get rid of it
Well I want to know why I'm getting failed to convert sources
I'd probably recommend trimming down the problem so you can reproduce it with closure only
-> Shadow JS converting 1861 JS sources
failed to convert sources
there's quite a few sources
well yes
hmm interesting. thats not very precise info. usually you get better errors than that 😛
well it's simple
com.google.common.base.Preconditions.checkNotNull
this checks, and if sth is null
it would throw the infamous one
but usually closure will at least include some kind of source location that caused the issue
looks like a weird place to fail? what are you including from npm? there shouldn't be goog.inherits
calls in there?
well maybe it also applies to class
and the comments just aren't updated. can't really tell 😛
okay 🙂 good to know!
well, one "suite" of interest is https://deck.gl/#/
others are React and related stuff, should be very common
in case anyone has some time to test stuff I just released 2.10.0
which includes a pretty significant rewrite of everything REPL. ideally nothing changes from the user perspective but I might have missed stuff.
it also enables Inspect and tap>
for everything by default, no need to manually enable it anymore
Can anyone suggest how to compile (`./build-all.sh` fails for me, is ./build-cli.sh
enough?) and use the compiled/customized shadow-cljs (i.e. what to run instead of npx shadow-cljs compile myns
)?
@andrewboltachev why are you messing with shadow-cljs when you want to debug a GCC issue in the first place?
@thheller well I just think it's the easiest way. 'cause shadow-cljs pushes that assets right through GCC
but what are you modifying in shadow-cljs itself? if you just want to change the dep you don't have to do that in shadow-cljs
you don't really need any of the build.sh scripts, they are mostly for CI and publishing. a regular lein install
should be enough.
just saying that you don't really need to touch shadow-cljs in any way if you are not making changes there.
ah so, it's not dependency-through?
GCC is a dependency of shadow-cljs yes but to change that dependency you don't need to change shadow-cljs?
i.e. of my own project then?
ah so that's no matter — the other ver. of GCC would be connected
let's see
aha! I'm seeing my ouput
CALL 2 [length: 30] [source_file: node_modules/turf-jsts/jsts.min.js]
okay, that tells that the problem is coming from turf modules
turf — sort of geospatial calculations module
and btw that's min file
ah so I should try to optimize it directly by GCC somehow probably
it is running through :simple
optimizations .. doesn't matter if its minified before or not
don't get side-tracked. figure out the source location that is causing this in the actual source.
if you do it might be easier to make a reproducible case and get this actually fixed in GCC
yes, great thanks!
I guess I'll summarize here then when I'll gather all the details
also comparing against different GCC versions maybe