do I not understand how boot-cljs works with compiler-options {:preloads '[my-dev-namespace.core]? when I run a compilation :advanced mode, the preloaded namespaces still show up, even if the build doesnt include the preload config at all?

@lwhorton preloads is only for dev mode iirc

Hello @micha, just realized that I won't be able to use pods since the dev tooling I was talking about yesterday was specifically tooling that needs to access the app runtime and vars. I'm talking about nice pretty-printers (in REPL or in external windows, think charts/graphs), spies, debug helpers etc. All of that needs to access the Vars and values in my running app. Am I right that pods won't work for this kind of tooling ?

Hi folks! Is there a boot task to generate an npm package for a CLJS project anywhere?

hmm.. this isn’t boot specific necessarily, but am I going crazy? nowhewre in the boot-cljs source do I see optimizations provided by the command-line actually being merged into a configuration somewhere: https://github.com/boot-clj/boot-cljs/blob/master/src/adzerk/boot_cljs.clj#L239-L242

@lwhorton *opts* is bound to the map of all options so that contains optimization settings etc

oh, huh. that’s pretty tricky.

i’m still going insane trying to figure out why a file I don’t reference with any :preloads configuration is showing up in my prod build… grasping at straws

@lwhorton you can try different verbosity levels -v -vv -vvv one will print all the cljs options passed to the compiler

hahaha.. that’s also a great way to lock-up and repeatedly crash iterm, apparently

{:output-dir
 "/Users/.../main.out",
 :closure-defines {"goog.DEBUG" false},
 :externs
 ["externs.js"
  ...],
 :optimizations :advanced,
 :source-map-path "main.out",
 :parallel-build true,
 :verbose true,
 :preloads nil,
 :output-to
 "/Users/.../main.js",
 :asset-path "main.out",
 :output-wrapper true,
 :source-map
 "/Users/.../main.js.map",
 :compiler-stats true,
 :main boot.cljs.main2757,
 :pretty-print false}

@lwhorton what kind of file is showing up in your build?

For those interested, preloads doesn’t work the way I thought. It simply loads the namespace ahead of main.core, but it doesn’t prevent it from being loaded in case it’s not listed in :preloads at all. In addition to this, binaryage/cljs-devtools doesn’t work with DCE unless it’s setup very specifically. (either behind a goog.DEBUG, or more preferably configured via the specific namespace [devtools.preload].

So my issue was that 1) cljs-devtools wasnt configured properly and 2) DCE doesn’t happen “automagically” via the lack of a :preloads to your namespace. Your namespace will still be loaded, and if you want dev-only side effects they still need to be hidden behind (when goog.DEBUG ...).

@lwhorton :preloads feature is effective only in :optimizations :none builds, se you must have been requiring cljs-devtools directly in your code under :advanced :optimizations

indeed I was, as well as misunderstanding how preloads works in general.

this might be more specifically related to boot

the analogous should be provided yes, but it is not as straightforward (it is java afterall): https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html