@thheller How can I generate the bundle-info.edn file for a build?

I though shadow-cljs release my-build would add it to the output, but I’m not seeing it

@colindresj I’m still messing around with the functionality. its not ready but you can run shadow-cljs clj-repl and then (shadow/release-snapshot :build-id)

it will be in target/shadow-cljs/release-snapshots/build-id/latest

if you are only after the bundle-info.edn thats fine.

@cmal can’t sleep and needed to code something so I did the keyword optimization we were talking about

test compiled my production app which is split into 4 modules

largest module went from 413761 bytes -> 406811 bytes before gzip and 53808 -> 52762 gzip’d.

doesn’t seem that great …

you can try it with [email protected] and setting :compiler-options {:shadow-keywords true}

I’m really surprised how little difference it actually makes

needs some more real world testing

3kb gzip across all 4 modules

should be much larger difference in reagent apps though

a lot more keywords

not sure how to test overall perf impact

Anyone gotten a fulcro project building with shadow-cljs? Getting an error about clojure.future not being on the classpath, which I'm pretty sure is from https://github.com/tonsky/clojure-future-spec.

nvm, rolling version back to 1.1.1 resolved it.

@thheller Excellent work! I will check how this will decrease my compiled and gzip'd file.

187304 -> 185424 for gzipped file

hmm thats like 1%.

@devo @mitchelkuijpers is using fulcro. clojure-future-spec is ignored by default since its a backport of clojure.spec to 1.8 but shadow-cljs already uses clojure 1.9

but it seems like that the backport was changed so it should be safe to require now

last time I checked it wasn’t safe to use. I will remove the removal so the clojure.future works again.

@cmal wrote a post about it, hope its ok that I used your numbers and mentioned you. https://clojureverse.org/t/feature-highlight-shadow-keywords/952

That is OK. Thanks @thheller

@thheller Very cool stuff. I'm envisioning keyword interning here 🙂

Btw, you probably wanna remove the console.log statement in the code

(in constants-inject)

hahaha OMG

should not code at 5am

😛

thx

Keyword interning could mean we can rewrite (= :foo a) to (identical? :foo a)

nah that can never work with :none

Well yeah, in production builds.

well it could work now that we have weak references (in some browsers)

Yeah browser builds only for interning keywords. No risk there. Doesnt' even need a weakref

Hi. I’m testing out shadow-cljs for a node cli tool. Looks cool so far - great project!

I’m looking at the release build output of a very simple hell-world:

(ns permafrost.main)

(def value-a 3)
(defonce value-b 2)


(defn reload!
  []
  (println "Code updated.")
  (println "Trying values:" value-a value-b))


(defn main
  [ & argv ]
  (println "App loaded:" argv))

the shadow-cljs.edn:

;; shadow-cljs configuration
{:source-paths
 ["src"]

 :dependencies
 [[cider/cider-nrepl "0.16.0-SNAPSHOT"]
  [refactor-nrepl "2.4.0-SNAPSHOT"]]

 :nrepl
 {:port 8202}

 :builds
 {:pf {:target :node-script
       :output-to "out/permafrost.js"
       :main permafrost.main/main
       :devtools {:after-load permafrost.main/reload!}
       :release {:output-to "permafrost.js"}}}}

@devo Send me a message if you need help, will publish a shadow-cljs starter with fulcro soon

the output is 838kb. I expected something smaller.

is my assumption or setup wrong?

@sundbp by default the node targets are just using :optimizations :simple due to larger number of externs required on node setups

so no dead code deleting?

try compiling with :compiler-options {:infer-externs :auto :optimizations :advanced}

some DCE is still done but much less aggressive. also no renaming happens since file size usually is not that important for node.

but the above settings will take care of that

then you get the full experience but might need to fix a few externs

ok. i was just surprised that not most got eliminated as i assumed just some println would bring in almost nothing

nah barely anything is removed in :simple

so with those settings it’s 85kb

sounds about right

cool. thanks

can get it even lower but then you can’t println or prn only console.log

but any real code will be about that size minimum since its cljs.core with the datastructures

right. made 1k diff to change to console.log

not worried about size - just verifying my understanding of what’s going on

another assumption: if i aim to package up an npm package with a cli tool using some npm packages. I put my dependencies in package.json, do my thing. the release build will not bring in any code from the npm packages into my output, right?

if you set :build-options {:print-fn :none} it should go down more

i.e. i’ll get an output that has all the code from the “cljs land”, but none from the “npm land” and hence fitting in nicely with npm

you can take a look at what I do for shadow-cljs itself

https://github.com/thheller/shadow-cljs/tree/master/packages/shadow-cljs

thats the package for npm

cool. will do

https://github.com/thheller/shadow-cljs/blob/master/shadow-cljs.edn#L29-L40 thats the build config

btw, I didn’t see any change with the print-fn change

oh you might need to wipe your cache

ah. the npm-module target. was reading the source on that one as no docs yet.

ah. how do i do that?

rm -rf target/shadow-cljs/builds/build-id …

I think I missed adding that setting to the cache-affecting-options 😉

cool

the :npm-module name is a bit misleading. you can use :node-library as well which is a bit smaller and better optimizable than :npm-module

I needed to a few “special” things thats why I used :npm-module

:node-script is fine too, thats how I started.

still see no effect of the :print-fn :none

with just (js/console.log "foo") in your code?

ah wait

(defn main
  [ & argv ]
  (println "App loaded:" argv))

remove the &

k 🙂

varargs keep some collection code alive

but really don’t go down this road .. it won’t get below 85k in any reasonable app

thats pretty much the minimum as soon as you use anything from cljs.core

understood. wasn’t the intention - just wanted to check my understanding of what was going on

as for the npm thing I recommend outputting into a dedicated directory with its own package.json. don’t use the one at the project root.

you can but you have to be really careful with devDependencies and such then

right. i figured it’d be pretty safe with devDependencies vs dependencies?

just have the right thing in the right category and you’ll get the right outcome?

yeah if you are careful it should work out.

cool

thanks a lot for the help - looks like the way to go for CLI tools in cljs for me!

i’m curious about closh using lumo to run its node output: https://github.com/dundalek/closh/blob/master/bin/closh.js

its pretty terrible to use lumo to do that if you ask me 😛

wonder if related to that --cache option?

lumo is great but having it check if something needs to be compiled before running it is not useful for production builds

much rather launch directly without all that overhead

yes. i don’t quite understand.. because they already do a cljsbuild via lein to get an :advanced optimization output..

closh is a different story since it needs runtime eval

ah. that’s why they want lumo, got it.

makes more sense now

still wouldn’t use lumo but its the easiest option for that

then the lumo+eval+cache thing starts to make sense.

but as I understand lumo is adding a way to build projects as well

yes, read some blog post about it

but don’t think any docs are about

i’d love closh to become a viable day-to-day shell.

seems cool yeah

so for shadow-clj cli you output to packages/shadow-cljs/cli/dist, install a bin runner.js that loads this file with some logic around how it’s finding the file. what’s the purpose of the runner here?

if shadow-cljs is installed globally it should still use the one installed in the project

thats what the runner does

ah, ok.

seems generally sensible

thanks. that’s all I was pondering - should work out well!

Nice new test support works awesome

I love removing the ns that includes al test nses

Something still goes wrong with reloading but that is because the fulcro-spec runner is macro I think

@mitchelkuijpers [email protected] also adds :target :karma which always produces one output file (missing source maps currently, will add later)

:test-karma
  {:target :karma
   :output-to "out/demo-karma/test.js"}

module.exports = function(config) {
  config.set({
    browsers: ['ChromeHeadless'],
    basePath: 'out/demo-karma',
    files: ['test.js'],
    frameworks: ['cljs-test'],
    plugins: ['karma-cljs-test', 'karma-chrome-launcher'],
    colors: true,
    logLevel: config.LOG_INFO,
    // FIXME: do we need this?
    client: {args: ["shadow.test.karma.init"],
    singleRun: true}
  })
};

Ah I already had it working with browser-test 😛

It even works with karma watch

oh really. with watch?

Yes

ah hehe I couldn’t figure out how to make that work

Hehe I wrote my own runner, sort of

(ns atlas-crm.CI-runner
  (:require
   [shadow.test :as shadow-test]
   [doo.runner :as runner :refer-macros [doo-tests]]))

(doo.runner/set-entry-point!
 (fn [tc]
   (let [total-tests (reduce
                      (fn [acc {:keys [vars]}]
                        (+ acc (count (keys vars))))
                      0
                      (vals (shadow-test/get-tests)))]
     (jx.reporter.karma/start tc total-tests))
   (shadow-test/run-tests (cljs.test/empty-env :jx.reporter.karma/karma))))

there is now shadow.test.env which has the get-tests fn

also a get-test-count fn 😉

had to split into a seperate namespace since shadow.test depends on cljs.test but shadow.test.env needs to be loaded before cljs.test

how does your karma config look then?

module.exports = function(config) {
  config.set({
    browsers: ['ChromeHeadless'],
    basePath: 'resources/public/',
    files: ['ci/js/test.js', {pattern: 'ci/js/cljs-runtime/**', included: false}],
    frameworks: ['cljs-test'],
    plugins: ['karma-cljs-test', 'karma-chrome-launcher'],
    colors: true,
    logLevel: config.LOG_INFO,
    client: {args: ["doo.runner.run_BANG_"],
    singleRun: true}
  })
};

and my shadow-cljs.edn

:ci {:target :browser-test
               :asset-path "/base/ci/js"
               :ns-regexp "-spec$"
               :runner-ns atlas-crm.CI-runner
               :test-dir "resources/public/ci/"}

Sorry have to run, hope it helps!

thx, it does.

I really love the shadow-test stuff btw

I have to fix fulcro spec I think since it uses macros

glad it works for you. yeah those macros are annoying with respect to reloading