Looking at this:

(defn compile* [build-config opts]
  (util/print-build-start build-config)
  (-> (util/new-build build-config :dev opts)
      (build/configure :dev build-config)
      (build/compile)
      (build/flush)
      (build-finish build-config)))

Where should I look to see where :output-to and :output-dir are getting set?

@ddrbt it is up to each individual target to control where output goes most targets set :build-options :output-dir to a java.io.File instance

usually only flush should write output so you could set it like this

(defn compile* [build-config opts]
  (util/print-build-start build-config)
  (-> (util/new-build build-config :dev opts)
    (build/configure :dev build-config)
    (build/compile)
    (assoc-in [:build-options :output-dir] (io/file "somewhere"))
    (build/flush)
    (build-finish build-config)))

cache files are a bit different but you probably don't need to touch that

I'm looking at switching our project over to shadow-cljs because it solves issues we're having using npm packages with cljsbuild. So far I can't see any reason not to move, pretty much everything seems to work the same or better. But experience tells me there can't be no down side at all. What are the trade-offs when using shadow-cljs?

@davidw I guess the biggest downside currently is that pretty much all editors/tools expect you to use leiningen. so if you want to use the standalone version of shadow-cljs you have to jump through a few hoops to make it work or use it via lein.

besides that I haven't used any other CLJS tools since 2013 and I can say with confidence that it fixes a whole lot of issues that are still present in standard CLJS

ok. It certainly looks to fix the issues I've been having. I'll give a try and see how it goes. Thanks.

This might be a stupid question because I don't know exactly how it works but could there ever be a situation in the future where some language feature was added to cljs that wouldn't work with shadow-cljs?

no.

great

in more than one instances features actually came to shadow-cljs before coming to CLJS itself

but language features itself should all be supported always since we are just using the same analyzer/compiler

that's what I thought but wanted to double check.

feel free to ask questions if anything is unclear. helps me figure out what issues people run into when transitioning from other tools.

thanks, I will do.

if I do shadow-cljs watch app should that pick up changes to the dependencies in shadow-cljs.edn?

:dependencies currently require a restart. I have some plans to fix that but its not finished yet.

build config changes will be picked up automatically

I see

I'm seeing some strange behaviour with devcards. The cards display ok but don't auto reload unless I add :after-load to the :devtools config. Even if the it points to a function that does nothing.

@davidw you can also set :autoload true. autoload is not enabled by default.

I guess I should enable it by default to match figwheel. many people seem to expect that.

ah, ok. I was confused because the little icon appears. I thought it was autoloading.

So what does the little spinner icon signify then? if it's not that the code as been updated?

comes in when the build starts and fades out when the build succeeds

ok so it just tells you there's been a build, not that the build has been loaded?

it is currently not coupled to the loading since we can't reliably say when the loading is completed due to async stuff you might be doing in :after-load

but if autoload is enabled it will most likely be finished before the icon disappears

since the animation takes a bit of time

I never considered the fact that the loading anim shows even when autoload is disabled

yes that seems strange to me

it really suggests that I'm getting the latest changes when icon is displayed.

yes, but what seems strange to you is that autoload is not enabled by default.

if it was enabled by default you'd probably never notice

the reason why its not enabled by default is simple

I still have some code in production that does not use react

autoloading only really works if you use react otherwise it can cause problems

but I guess I should enable it by default just because of figwheel

sames to be the more optimal choice given what people expect

no, I don't think that's what's strange. if I was changing the code I didn't see the icon I would assume it's not autoloading and go look for how to turn it on. it's more that if the browser that I'm looking at isn't getting changes why have the icon show at all?

and also why have the websocket connection?

REPL

as soon as I pressed enter that popped into my head 🙂

of course

also you will still see warnings and errors even with autoload disabled

cool

Is there a way to indicate to shadow whether to use yarn or npm for installing packages it finds in deps.cljs files in dependencies?

trying to figure out how to manage JS dependencies that are pulled in from other deps. let’s say I am requiring library "a", and it only comes from some library Lib my app depends on. step 1, first compile: shadow-cljs installs version 1 of "a" because that is what is listed in a deps.cljs file in Lib. This is added to the local package.json. step 2: Lib updates their deps file to version 1.1 of "a". step 3: after upgrading to new version of Lib, we compile again. The local, auto-installed version of "a" will not be upgraded, but a warning is printed. I think the only thing one can do here is manually update the local package.json file whenever a warning like this appears?

That’s what I’ve been doing @mhuebert, I hope there’s a better way, but haven’t spent the time to investigate

Any time I see the warning I pretty much just yarn remove a then run shadow again

shouldn’t i be able to change ["react-dnd-html5-backend" :default HTML5Backend] into [react-dnd-html5-backend :as react-dnd-html5-backend :refer (default) :rename {default HTML5Backend}]? When I do that, I get a perplexing runtime error: Uncaught ReferenceError: react_dnd_html5_backend is not defined on this line of code (react-dnd/DragDropContext HTML5Backend). I’m confused that it complains about react_dnd_html5_backend instead of complaining about default or HTML5Backend maybe.

hm well just referring to react_dnd_html5_backend/default works, so nevermind

I don't recall seeing these before, but everything seems to work regardless:

------ WARNING #1 --------------------------------------------------------------
 File: bide/impl/helpers.js:29:41

 variable toString is undeclared
--------------------------------------------------------------------------------

------ WARNING #2 --------------------------------------------------------------
 File: com/cognitect/transit.js:649:8

 variable module is undeclared
--------------------------------------------------------------------------------

------ WARNING #3 --------------------------------------------------------------
 File: com/cognitect/transit/impl/writer.js:256:8

 variable isObject is undeclared
---------------------------------------

nm, doesn't happen in 2.2.6

@theasp the bide warning ios definitely correct. https://github.com/funcool/bide/blob/master/src/bide/impl/helpers.js#L29 toString is not declared. the transit warnings are also correct but its in conditional node code so it doesn't matter much.

shadow-cljs ftw

I hate how common things like this are: '[object Array]' == toString.call(val)

@mhuebert conflict resolution with :npm-deps is icky. yarn will be used if a yarn.lock exists. there is this obscure and totally not official :node-modules {:managed-by :yarn} setting you can set in the shadow-cljs.edn top level as well.

@lee.justin.m shadow-cljs complains like this?

@thheller shadow-cljs compiled it just fine. the error i got was runtime

it’s not a big deal because using the default property is really fine

i don’t want to use the string literal requires because it stops my linter from working

there is definitely something weird going on with the rename

please open a github issue so I don't forget

okay sure

done