Fork me on GitHub

Morning guys, I’ve got a question about moving resource files. I have this resource file that I’ve packaged in a JAR, and everytime that project JAR is used, I’d like boot to copy a particular file in that JAR into the project’s designated resource directory.


I’ve tried using the (sift :to-resource…) command in the build.boot to move that file over, but it claims it can’t find it in the fileset. Do I need to extract it from the JAR into the fileset first (ie using the (sift :add-jar… command?


Hi! Just getting started with boot. I'm testing ClojureScript using boot-cljs-test and would like to use humane-test-output.


I've required pjstadig.humane-test-output in my build.boot, but I don't see any change in behavior. Likely it's just me not knowing how to add this to my set up. Or maybe this needs to be included in boot-cljs-test?


Heya guys, I’m a little confused as to what changed in boot-reload. Something between .4.8 and .4.12 broke what was previously working for me. I have taken a look over all the commits and I’m not positive why this change is breaking, but I know where (i think). The behavior that was previously working was this: I use a custom css preprocessor that runs through a boot task and converts stylus markdown into a clojurescript module. When loaded, the module refers to a runtime, and the runtime creates a <style> tag or updates an existing <style> tag. I use a defonce styles (atom nil), then store all tags inside that atom to make sure i’m not duplicating tags or not properly overwriting old styles in existing tags. After some digging around I see that the changed-uri and normalize-href-or-uri function doesn’t seem to consider this case: I have a <link href=“/styles.css”> on the page, and a file /foo/styles.css changes. The normalization just looks at ends-with? and then will incorrectly replace my /styles.css ownerNode href with /foo/styles.css. Like I said, I’m not really sure yet why this didn’t happen previously...


Also not exactly sure why this particular /foo seems to be clobbering the /styles.css, unless it’s purely coincidental with the index of the files inside of reload-css.

lwhorton18:10:39 this is the reference line that changed, but there’s nothing there to convince me that this bug didn’t actually exist before the change, and I’m somehow miraculously just noticing it now?


The outcome behavior, btw, is that the /styles.css sheet essentially gets erased, clobbering a set of styles I have on the page, because /foo/styles.css isn’t really a “loadable” css file.


——————— Totaly unrelated to the above, but just as curious… is there a reason the very first change triggered by watch seems to completely ignore the whole pattern of [diff (c/fileset-diff @prev fileset)] for ‘caching’ the different filesets between changes? If I run a boot task, it will run the task for all the files - then after a change to one file, it will run the task through all the files again, as opposed to just the changed file, but this only happens on the first change.