Fork me on GitHub
#shadow-cljs
<
2020-06-04
>
awb9901:06:34

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!

Rob Knight08:06:33

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.

thheller08:06:06

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.

thheller08:06:02

but I haven't checked in a while how much this actually leaves behind

thheller08:06:27

likely still too much

Rob Knight08:06:02

Thanks! I'll try that.

thheller08:06:02

you can try setting up something like this https://github.com/day8/re-frame-debux/issues/30

thheller08:06:31

ie. create a stub ns that actually does nothing and also doesn't require any additional dependencies

thheller08:06:08

that would ensure that everything is gone

Rob Knight08:06:19

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.

Rob Knight08:06:54

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?)

thheller08:06:33

ah yeah thats the common approach. you basically just replace the ghostwheel dependency on the classpath with the stubs

thheller08:06:56

but that requires changing the classpath for dev/release builds which I think is a bit icky

thheller08:06:31

but yeah you can take the stub ns it has, name it ghostwheel.core-stubs or so

thheller08:06:22

{:builds
 {:app
  {:target :browser
   ...
   :release
   {:build-options
    {:ns-aliases
     {ghostwheel.core ghostwheel.core-stubs}}}}}

Rob Knight08:06:46

Aha. I couldn't find a single example of anyone actually doing this on github.

thheller08:06:25

well this method nobody has done for ghostwheel

thheller08:06:16

the typical method just uses different dependencies and switching the alias/profile using deps.edn/lein

thheller08:06:58

aliasing the ns is only supported by shadow-cljs and I haven't documented it much so it isn't exactly widely used 😛

Rob Knight08:06:50

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?

gnl18:06:09

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.

Rob Knight08:06:30

That makes sense. Thanks!

David Pham09:06:36

In general, what can go into the :build-options key?

David Pham09:06:02

I did not find anything in the docs

thheller10:06:30

most of them are for internal stuff you shouldn't worry about

thheller10:06:56

I'll try to document the few that you can actually use

David Pham11:06:02

Thanks a lot! I really liked ns-aliases

David Pham11:06:12

It saved my ass today for devcards 0.2.7

martinklepsch11:06:12

Is there a way to build code in release mode while triggering new builds whenever a file changes?

thheller11:06:41

@martinklepsch no. I'd recommend triggering the compile from the REPL.

martinklepsch11:06:15

Ok, guess I’ll try to hook that up to a watcher than. For debugging advanced issues this is quite handy

martinklepsch11:06:44

(I’m back to debugging our node source maps issues 😅)

thheller11:06:24

shadow-cljs release app --pseudo-names while shadow-cljs server is running is what I typically do

thheller11:06:53

: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

thheller11:06:06

leading to many useless compiles ... (at least in my experience)

martinklepsch11:06:10

yeah I realized that might be an issue

Vishal Gautam14:06:40

is there a way to restart the server after installing cljs dependences without killing the previous process?

Vishal Gautam14:06:27

it works with npm dependences, but when i install cljs dependency, I always have to kill the process and restart it

thheller14:06:51

there is not no.

p4v4n14:06:33

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

thheller15:06:20

@p4v4n any errors during load?

p4v4n15:06:32

@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)

p4v4n15:06:22

On component load

Uncaught Error: Assert failed: Invalid Hiccup form: [nil {}]

thheller15:06:52

ok nothing will work after that error

thheller15:06:04

which shadow-cljs version is that?

thheller15:06:22

$jscomp issues should be fix in more recent versions?

p4v4n15:06:53

shadow-cljs version is 2.9.3. The reference error is happening only when this particular library is loaded.

p4v4n15:06:11

@thheller Tested it with 2.9.10. Still facing the same issue. (upgraded version - lein deps - lein run)

thheller15:06:15

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}

thheller15:06:34

$jscomp issues should be fixed but I don't know enough about your setup to comment further

thheller15:06:53

if you make a reproducible example I can take a look later

p4v4n15:06:49

Thanks a lot.Will try that.

p4v4n15:06:59

@thheller After adding :compiler-options {:output-feature-set :es6} the reference error disappeared. Able to use the library now.Thanks.

jaime16:06:20

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?

thheller16:06:08

use the fully qualified namespace. (shadow.cljs.devtools.api/repl ...)

thheller16:06:26

otherwise it depends on which namespace you are in and only works in shadow.user by default.

jaime16:06:56

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"}}}

thheller16:06:35

and how did you start things?

thheller16:06:45

jsut the watch?

thheller16:06:45

you have use port file from nrepl file activated

thheller16:06:53

that only works with more recent versions of cursive

thheller16:06:10

otherwise it uses .nrepl-port which shadow-cljs doesn't create

thheller16:06:22

looks to me like you are just not connected to the correct nrepl server

thheller16:06:03

maybe configure :nrepl {:port 12345} and connect to that port directly

jaime16:06:41

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

jaime16:06:56

ok. My bad. I think I'm pointing to the wrong symbolic link.

jaime16:06:12

It is one directory up 😅

jaime16:06:06

thanks @thheller for your help, appreciate it

jaime16:06:22

I should put readme file on this project. I always get stuck like an hour before I figure out how to connect to repl 😆

thheller16:06:03

cursive in EAP supports looking at the .shadow-cljs/nrepl.port file directly so that gets a bit easier 🙂

jaime16:06:15

cool 🙂 looking forward to it

andrewboltachev16:06:52

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.

andrewboltachev16:06:57

Note: I'm using java-11-openjdk-amd64

thheller16:06:55

thats a class from the closure-compiler so maybe a build issue?

andrewboltachev16:06:40

ah so is this shadow-cljs/src/main/com/google/javascript/jscomp/ShadowAccess.java actually taken from GCC?

thheller16:06:15

no. the ProcessDefines is from GCC

thheller16:06:21

that class is in the shadow-cljs repo because it accesses a bunch of package-protected stuff shadow-cljs can't otherwise access

thheller16:06:39

dunno if they maybe removed that define?

andrewboltachev16:06:37

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

thheller16:06:36

well yeah this stuff isn't part of any public API so it breaks quite frequently

thheller16:06:37

faster for me to just access this stuff directly to fix certain annoyances rather than going for a github issue and waiting 2 years 😛

andrewboltachev16:06:14

or Google Groups? 🙂

thheller16:06:28

good to know there is a breaking change coming up though 😉

andrewboltachev17:06:30

btw you're right. I've messed the jars a little bit, needed to specify the exact one I need to compile

andrewboltachev17:06:25

they get rid of it

thheller16:06:41

well google groups are pretty much dead

thheller16:06:09

what are you trying to do in closure exactly?

andrewboltachev16:06:43

Well I want to know why I'm getting failed to convert sources

thheller16:06:56

I'd probably recommend trimming down the problem so you can reproduce it with closure only

andrewboltachev16:06:26

-> Shadow JS converting 1861 JS sources
failed to convert sources

thheller16:06:35

otherwise you'll drastically reduce your chances of getting a PR through 😛

thheller16:06:43

there should be more to that error?

andrewboltachev16:06:50

there's quite a few sources

thheller16:06:42

hmm interesting. thats not very precise info. usually you get better errors than that 😛

andrewboltachev16:06:00

well it's simple com.google.common.base.Preconditions.checkNotNull

andrewboltachev16:06:19

this checks, and if sth is null it would throw the infamous one

thheller16:06:35

well yeah that is clear

thheller16:06:46

but usually closure will at least include some kind of source location that caused the issue

thheller17:06:03

looks like a weird place to fail? what are you including from npm? there shouldn't be goog.inherits calls in there?

thheller17:06:23

well maybe it also applies to class and the comments just aren't updated. can't really tell 😛

andrewboltachev17:06:52

okay 🙂 good to know!

andrewboltachev17:06:10

well, one "suite" of interest is https://deck.gl/#/

andrewboltachev17:06:38

others are React and related stuff, should be very common

thheller17:06:44

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.

12
thheller17:06:37

it also enables Inspect and tap> for everything by default, no need to manually enable it anymore

thheller17:06:06

I'll probably post an update about Inspect this weekend or so

andrewboltachev18:06:54

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 )?

thheller19:06:58

@andrewboltachev why are you messing with shadow-cljs when you want to debug a GCC issue in the first place?

thheller19:06:18

just use deps.edn and declare the GCC version you want to use

andrewboltachev20:06:33

@thheller well I just think it's the easiest way. 'cause shadow-cljs pushes that assets right through GCC

thheller20:06:15

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

thheller20:06:28

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.

thheller20:06:44

just saying that you don't really need to touch shadow-cljs in any way if you are not making changes there.

andrewboltachev20:06:12

ah so, it's not dependency-through?

thheller20:06:25

GCC is a dependency of shadow-cljs yes but to change that dependency you don't need to change shadow-cljs?

thheller20:06:38

just override it directly from lein or deps.edn

andrewboltachev20:06:54

i.e. of my own project then?

andrewboltachev20:06:20

ah so that's no matter — the other ver. of GCC would be connected

thheller20:06:35

what do you use? project.clj or deps.edn?

andrewboltachev20:06:49

aha! I'm seeing my ouput

andrewboltachev20:06:51

CALL 2 [length: 30] [source_file: node_modules/turf-jsts/jsts.min.js]

andrewboltachev20:06:10

okay, that tells that the problem is coming from turf modules

andrewboltachev20:06:26

turf — sort of geospatial calculations module

thheller20:06:35

there is more info about the location a node came from

andrewboltachev20:06:25

and btw that's min file

andrewboltachev20:06:40

ah so I should try to optimize it directly by GCC somehow probably

thheller20:06:19

it is running through :simple optimizations .. doesn't matter if its minified before or not

thheller20:06:02

don't get side-tracked. figure out the source location that is causing this in the actual source.

thheller20:06:25

if you do it might be easier to make a reproducible case and get this actually fixed in GCC

andrewboltachev20:06:46

yes, great thanks!

andrewboltachev20:06:59

I guess I'll summarize here then when I'll gather all the details

andrewboltachev20:06:09

also comparing against different GCC versions maybe

thheller20:06:35

don't try too many different GCC versions with shadow-cljs. its going to break pretty soon as you already saw 🙂

thheller20:06:45

its usually every other release that breaks somethings

thheller20:06:08

or just replace the turf-jsts lib if you can, thats probably the easier route