Fork me on GitHub
#boot
<
2017-07-28
>
lwhorton02:07:50

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?

richiardiandrea06:07:08

@lwhorton preloads is only for dev mode iirc

djebbz08:07:40

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 ?

jannis13:07:48

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

lwhorton15:07:11

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

martinklepsch15:07:47

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

lwhorton15:07:03

oh, huh. that’s pretty tricky.

lwhorton15:07:38

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

martinklepsch15:07:26

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

lwhorton15:07:36

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

lwhorton15:07:43

{: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}
There must be an issue elsewhere, looks like the proper args are getting passed through. Thanks @martinklepsch :+1:

martinklepsch16:07:28

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

lwhorton16:07:10

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].

lwhorton16:07:22

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

darwin16:07:28

@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

lwhorton16:07:24

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

lwhorton17:07:01

this might be more specifically related to boot

richiardiandrea17:07:54

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