Fork me on GitHub

I'm a little stuck here. Not quite sure what order I am supposed to be adding Figwheel in on the run task. I feel as though a lot of the tasks will be consumed by figwheel as it has so many options. Can someone point me in the right direction?

   {:build-ids  ["dev"]
    :all-builds [{:id "dev"
                  :source-paths ["src"]   ; cljs(cljc) directories
                  :compiler {:main '
                             :output-to "js/app.js"}
                  :figwheel {:build-id  "dev"
                             :on-jsload '
                             :heads-up-display true
                             :autoload true
                             :debug false}}]
    :figwheel-options {:open-file-command "emacsclient"
                       :repl true}})

(deftask build []
  (comp (speak)
        (garden :styles-var 'new-app.styles/screen
                :output-to "css/garden.css")))

(deftask run []
  (comp (serve)
       ; (figwheel)

(deftask production []
  (task-options! cljs {:optimizations :advanced}
                      garden {:pretty-print false})

(deftask development []
  (task-options! cljs {:optimizations :none :source-map true}
                 reload {:on-jsload '}

(deftask dev
  "Simple alias to run application in development mode"
  (comp (development)


Hey folks! When I build an uberjar, I'll typically want to extract it from target/ and push it somewhere. Is there a task to do that (e.g. drop the jar in an arbitrary directory) without having to use the target task?


And without install?


I guess the best solution is to not drop the file somewhere for manual copying around but to push it to a Maven repository straight away. So I'll do that.


@jannis I don't know of a written task - but I would probably be looking at doing a sift first, to get just the uberjar in the resulting fileset, then a simple task to push it wherever you like. If you just want to stick it into a directory, you could use target with :no-clean and I think that would do what you want.


@dominicm Yeah, shouldn't be hard to write a simple task like that. I was just wondering whether there is one out there already.


@grounded_sage what are you trying to accomplish?


have you seen boot-cljs?


@grounded_sage I think your assumption is correct. You don't want references to boot-cljs/boot-cljs-repl and maybe even reload anymore


@dominicm: are you familiar with Boot and Figwheel? I had a little bit of hacking today but couldn't seem to get it to work fully. Everything was working except I had to refresh the browser to view the changes.


@pesterhazy: I am working towards having Figwheel and Devcards in my workflow. The friendliness of error messages in Figwheel and the awesome sauce that is Devcards for development I just can't go without.


Only independently of each other. You're in pretty fresh territory doing this.


Is devcards tied to figwheel? ouch.


Devcards isn't inherently tied to figwheel based on a skim of the readme. So I think you can use it with boot-cljs


boot-reload does have error messages, the only thing I've noticed that's missing is the code window.


@grounded_sage If you had boot-reload or boot-cljs running with figwheel, I'd not be surprised if they broke figwheel's reload injection.


Yea Devcards can be used independently. But I was unable to get it working before I decided to take a break. With respect to Figwheel it seems like I need to get it to take over the compiling of cljs, pick up changes of garden styles, reload and the repl.


It's almost a build tool in it's own right. I think this is why boot-cljs/boot-cljs-repl/boot-reload/watch is the preferred method - entirely swappable parts that work independently.


Yea I have been working off that and trying to integrate it into the current build file but I'm not as familiar with either of the tools as I should be to be tackling this task! Haha


I would highly recommend using the normal boot stack 🙂 especially for getting familiar with boot.


I genuinely think it's 90% of figwheel on it's own - without having boot-cljs doing any other frontend compilation.


Yes I stepped back from it today and tried to just get Devcards in there but had no luck. Was pretty drained by that time so I might give it another crack tomorrow.


Basically trying to get a good workflow with Boot so I can build JAM sites and host them on Netlify and start up some web consulting. As I home my Clojure chops.


Pretty sure you can pretty much drop that cljs.edn file in and tweak the namespaces to get what you want 🙂


I was going to knuckle down with Leiningen but Boot seems like it would give me better ROI for my time.


Cheers looking on computer now


Definitely go back to your pre-figwheel version and try again with devcards.


It's easier than figwheel right now


That one from hashrocket throws errors at me when I try and run the demo


looks like I got it working just had to remove cljc and clj from resource paths. I was working off this one today which seems similar.


On top of the edn file you also need to add :compiler-options to the cljs compiler.

(cljs :compiler-options {:devcards true})


@grounded_sage I'm also using as a basis and it works like a charm in my boot-based project


devcards is a blessing during development


which is why I am so determined to have it. Figwheel would also be great as the new error messages are Fan ingtastic. But I can live without at this point in time.


yay I got devcards working pretty seamlessly now. I'll be back for Figwheel another day 😛


@grounded_sage I am trying boot-figwheel as we speak but no success so far, I'll keep you posted 😉


@grounded_sage how are they different to those of the boot toolset? (error messages)


@dominicm you get source snippets with the error-line highlighted in the reload UI


@martinklepsch it is just that? I don't think that's huge, is it?


I'm also pretty sure the boot reload code could be extended to do that.


definitely, just no one has done it 😄


:28 is my jam :). I'll probably not get annoyed enough to do this one.


same here (unfortunately)


@dominicm: yes you get a snippet of source code with the exact spot that caused the error. Both in the heads up display and in the repl. Not that big of a deal. But I'm still new to programming and typos are my biggest source of frustration as there had been times I have read the code like 20 times all the way through and haven't seen the silly mistake.


@grounded_sage I think boot cljs should give you warnings, indicating the line number and column?


Your editor should make it trivial to open that position


Maybe we should create an issue with some starting points so someone else who's motivated could pick it up easily...