HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
emezeske
lein-cljsbuild
Clojure2011–2014
emezeske / lein-cljsbuild

lein-cljsbuild

Leiningen plugin to make ClojureScript development easy.

11Distinct people
11Mentions
0Explicit recommenders
1.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Leiningen plugin to make ClojureScript development easy.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year11 dated mentions

Observed mentions: 2011-12-31 05:54:37 UTC to 2014-12-24 07:39:27 UTC.

0123452011-01-01 00:00:00 UTC to 2012-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20112012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2014

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20112011-01-01 00:00:00 UTC2012-01-01 00:00:00 UTC110
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC202
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC505
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC303

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
lein-cljsbuild Latest version: This is a Leiningen plugin that makes it quick and easy to automatically compile your ClojureScript code into Javascript whenever you modify it. It's simple to install and allows you to configure the ClojureScript compiler from within your project.clj file. Beyond basic compiler support, lein-cljsbuild can optionally help with a few other things: Launching REPLs for interactive development Launching ClojureScript tests The latest version of lein-cljsbuild is 1.1.8. See the release notes here. Note that cljsbuild crossovers are deprecated, and will be removed eventually. You should never use them. Please use either reader conditionals (available in Clojure >= 1.7.0-beta2 and ClojureScript >= 0.0-3255), or cljx to target both Clojure and ClojureScript from the same codebase. If you are using ClojureScript >= 1.7.170 you need to use a lein-cljsbuild version >= 1.1.1. Requirements The lein-cljsbuild plugin works with Leiningen version 2.1.2 or higher. Installation You can install the plugin by adding lein-cljsbuild to your project.clj file in the :plugins section: (defproject lein-cljsbuild-example "1.2.3" :plugins [[lein-cljsbuild "1.1.8"]]) In addition, you should add an explicit ClojureScript dependency to your project using the ClojureScript version you want to use: :dependencies [[org.clojure/clojurescript "1.9.521"]] lein-cljsbuild will add a dependency to your project if it doesn't already contain one, but that functionality will not remain for long. The latest version of lein-cljsbuild currently requires a minimum of ClojureScript 0.0-3211. Just Give Me a Damned Example Already! See the example-projects directory for a couple of simple examples of how to use lein-cljsbuild. The simple project shows a dead-simple "compile only" configuration, which is a good place to start. The advanced project contains examples of how to use the extended features of the plugin. For an exhaustive list of all options supported by lein-cljsbuild, see the sample.project.clj file. For a list of options that can be passed to the ClojureScript compiler have a look at the ClojureScript Compiler Options site. Basic Configuration The lein-cljsbuild configuration is specified under the :cljsbuild section of your project.clj file. A simple project might look like this: (defproject lein-cljsbuild-example "1.2.3" :plugins [[lein-cljsbuild "1.1.8"]] :cljsbuild { :builds [{ ; The path to the top-level ClojureScript source directory: :source-paths ["src-cljs"] ; The standard ClojureScript compiler options: ; (See the ClojureScript compiler documentation for details.) :compiler { :output-to "war/javascripts/main.js" ; default: target/cljsbuild-main.js :optimizations :whitespace :pretty-print true}}]}) Basic Usage Once the plugin is installed, you can build the ClojureScript once: $ lein cljsbuild once Or you can have lein-cljsbuild watch your source files for changes and automatically rebuild them. This is recommended for development, as it avoids the time-consuming JVM startup for each build: $ lein cljsbuild auto Assuming you have configured cljsbuild to emit compiler output to one of Leiningen's :clean-targets (which includes ./target by default), running lein clean will delete all of the JavaScript and ClojureScript files that lein-cljsbuild generates during compilation. Color-coded output on Windows Colors are a big deal when reading ClojureScript compiler output, but Windows consoles don't support ANSI color codes. This limitation is commonly corrected by installing ANSICON: Download and unzip ANSICON anywhere. Open a command prompt (Run as administrator). Navigate to the unzipped folder. cd x86 or x64 (depending on whether you have 32-bit or 64-bit machine, respectively) Run ansicon -i to install. Afterwards, you should get colored output from all future console sessions that use ANSI color codes. Hooks Some common lein-cljsbuild tasks can hook into the main Leiningen tasks to enable ClojureScript support in each of them. The following tasks are supported: $ lein compile $ lein test $ lein jar To enable ClojureScript support for these tasks, add the following entry to your project configuration: :hooks [leiningen.cljsbuild] Note that by default the lein jar task does not package your ClojureScript code in the JAR file. This feature needs to be explicitly enabled by adding the following entry to each of the :builds that you want included in the JAR file. lein uberjar derives its behavior from lein jar and will include the ClojureScript as well if enabled. :jar true Debug Note: There is a known issue (#366) where the lein uberjar task fails to build when using hooks and a cljsbuild configuration within an :uberjar profile. Instead of hooks, you can use :prep-tasks as an alternative: :prep-tasks ["compile" ["cljsbuild" "once"]] Multiple Build Configurations If the :builds sequence contains more than one map lein-cljsbuild will treat each map as a separate ClojureScript compiler configuration, and will build all of them in parallel: (defproject lein-cljsbuild-example "1.2.3" :plugins [[lein-cljsbuild "1.1.8"]] :cljsbuild { :builds [ {:source-paths ["src-cljs-main"] :compiler {:output-to "main.js"}} {:source-paths ["src-cljs-other"] :compiler {:output-to "other.js"}}]}) This is extremely convenient for doing library development in ClojureScript. This allows cljsbuild to compile in all four optimization levels at once, for easier testing, or to compile a test suite alongside the library code. You can optionally assign an ID to a build configuration and build only that one: (defproject lein-cljsbuild-example "1.2.3" :plugins [[lein-cljsbuild "1.1.8"]] :cljsbuild { :builds [ {:source-paths ["src-cljs-main"] :compiler {:output-to "main.js"}} {:id "other" :source-paths ["src-cljs-other"] :compiler {:output-to "other.js"}}]}) $
Read the full README on GitHub

What Hacker News says

11 sources
It's definitely a lot to take on. I'd probably start with just plain Clojure to learn the syntax and how to do functional programming, then look into ClojureScript. Get comfortable using Lein and editing your project.clj, then check out this plugin: https://github.com/emezeske/lein-cljsbuild It's a big investment but learning Lisp will repay you. There's tons of classic CS literature that you'll now be able to unlock and immutability really is the future, so it's good to start getting acquainted with it.
In Removing User Interface Complexity, or Why React is Awesome
Would you articulate why it's a "no go" for you? Leiningen[1] takes away 99.9% of the pain of having to work directly with javac, maven, classpaths, etc. And lein-cljsbuild[2] offers a configuration-driven approach to compiling and testing. It's perfectly possible to create setups where node (plus grunt, gulp, shell scripts, make, etc.) "drives" leiningen, and vice versa. About a year ago I contributed such a setup[3] to David Nolen's mori library. [1] http://leiningen.org/ [2] https://github.com/emezeske/lein-cljsbuild [3] https://github.com/swannodette/mori/blob/master/package.json...
In The JavaScript Problem
Didn't see this survey in time to contribute, but I'm one of the tinkerers who's used CLJS more than Clojure. Most of what I've been interested in doing is in-browser. For my last project[1] I used a regular Clojure REPL to clarify my understanding of the standard lib and paste in little functions for testing. Don't remember why I didn't use a browser-connected ClojureScript REPL. Maybe it just didn't seem worth typing "rlwrap lein trampoline cljsbuild repl-listen" when I can type "lein repl" :P My biggest wish is for the ClojureScript compiler to be less accepting of stupid code. I've made all kinds of moronic mistakes[2] that would ideally yield a warning or even a straight-up error, right at the source, but they don't and I just end up finding data structures full of nils at runtime. I've also hit a few traps with lein-cljsbuild[3][4].
Read the rest
This is all definitely improving though. I've now started my first real Clojure project, a web app built on Luminus[5]. Luminus kind of strikes me as training wheels for Clojure. It's easy to get started with, and minimizes the sense of foreign-ness coming from a Python web development background. But I doubt I'll still use it once I have more experience, as opposed to simply putting its component libraries (Compojure, Ring, lib-noir, etc.) into a project directly. Which is fine; it fills a valuable role in the ecosystem anyway. 1. https://github.com/graue/dumbbell 2. Example: http://dev.clojure.org/jira/browse/CLJS-639 3. https://github.com/emezeske/lein-cljsbuild/issues/239 4. https://github.com/emezeske/lein-cljsbuild/issues/248 5. http://www.luminusweb.net/
In Results of the 2013 State of Clojure and ClojureScript survey
I'm also not impressed with the Clojure/ClojureScript code-sharing story, which requires hacks[2] to use the same code on the client and server. I think this is definitely a "the glass is half-empty" interpretation. I mean, let's point out that you're complaining about an environment where you can share code between a codebase running on the server and one on the client--and it isn't JavaScript. And it's not ideal? Of course it's not ideal. But you can do inter-op with Java (server-side) and JavaScript (client-), using the same syntax, and with cljx, you can do this in the same file. This is freaking awesome, even with the messy bits that come along with it, in my opinion. A smaller community, fewer libraries and less mature tools makes it kind of a bummer from a social perspective. As far as this point, there's less I can disagree w
Read the rest
ith: the community, while small, is awesome, but there is a way to go before ClojureScript, at least, is going to have the ease of "install and get going" that you have with other platforms. Everything from testing to getting a reasonable console up and running is in a state of flux and cannot be favorably compared to JavaScript, other than the argument that ClojureScript provides a better enough programming experience to outweigh the ease-of-setup that JS provides. For me that's more than enough, but for others I can understand that it's not, yet. But it absolutely is improving, very quickly. We really need more people to be using CLJS and hyping it (as David Nolen is doing) and putting in the time to shave the yaks that need shaving--as people like David Nolen, Kevin Lynagh (http://keminglabs.com/blog/cljs-app-designs/ as well as the aforementioned cljx), Chas Emerick (many contributions, but recently https://github.com/cemerick/austin), Mimmo Cosenza (the fantastic Modern CLJS series: https://github.com/magomimmo/modern-cljs) and many others are doing--so that we can get to that point where the advantages clearly outweigh the disadvantages. I think that time will come, but it's going to require some serious work. But even now there are compelling reasons to use ClojureScript, including libs like core.async. I think you'd find that, with a bit of patience, there is a lot there to keep you invested in the tools and the community. EDIT: I just want to add that cljx is not the only or oldest or simplest way to share code. Crossovers using lein-cljsbuild have provided this for a while: https://github.com/emezeske/lein-cljsbuild/blob/master/doc/C...
In Make No Promises
I'm going through "ClojureScript Up and Running" right now, and I'd also recommend it. However, for folks who just want to give cljs a try, lein-cljsbuild does make it pretty easy at this point. Once you have lein and the lein-cljsbuild plug-in installed, the basic information on how to get a project up and running is here: https://github.com/emezeske/lein-cljsbuild#just-give-me-a-da... They also include example projects in the lein-cljsbuild repo that make use of some of the popular clojure web libraries like ring and compojure: https://github.com/emezeske/lein-cljsbuild/tree/master/examp...
In ClojureScript: Things That Might Worry You, but Shouldn't (2012)
Use lein-cljsbuild to compile ClojureScript as soon as the file change is made. After the intial JVM startup, compilation is instant. https://github.com/emezeske/lein-cljsbuild -- more -- ClojureScript is the Clojure language compiler that targets JavaScript. It compiles to Google Closure (not Clojure) JavaScript, but it can also target NodeJS. ClojureScript lets you use Clojure in the browser, adds Clojure data types to the JavaScript language, and allows for JavaScript to interact with the Clojure datatypes. Here's the side by side comparison https://himera.herokuapp.com/synonym.html One of the most obvious additions to JavaScript is the ability to partition your JavaScript with namespaces.
In ClojureScript's persistent data structures in vanilla JavaScript
Advantage for a beautiful demo. If I'm going to actually build real applications in this way, I don't need to run my development environment on someone else's website. The key benefit of having an in-browser implementation of something like Clojurescript isn't: "I can run my dev environment on the web." it's: "There IS no dev environment." Look at how absolutely trivial and frictionless it is to get started with LessCSS[1], and compare it to the morass of libraries, source file locations, command-line invocations, and extra compilation steps that Clojurescript requires[2]. You can introduce someone to LessCSS and have them working with it in five minutes. No cross-platform problems, no installation, no figuring out how to automatically compile code when it changes, or anything else like that. Once you need the extra sp
Read the rest
eed, sure, have a command line tool to precompile everything to vanilla JS. LessCSS has this exactly. Heck, sure, maybe even run it through the Closure compiler if you want crazy speed. But don't optimize the development process for huge apps at the expense of small ones, because even if you only care about those huge apps (which would be a mistake -- there are some really cool small apps out there) you need people writing smaller stuff first to learn how to use Clojurescript, create libraries for it, convince others to use it, and so on. Before anyone screams at me that I'm caring too much about that filthy concept of "easy", let me say that I loved Rich's talk on Simple and Easy, but I feel like it may have actually done some harm to the Clojure community by giving them an excuse for making conceptually-simple but hard-to-get-started-with-and-use libraries and tools. Simple is more important than easy, yes, but if you can make something easier without sacrificing simplicity then you should! No one should say "I don't have to thoroughly document this because it's conceptually simple so you should just read the code", or "we're going to make something that has lots of uncomplected layers and who cares if it's performant enough for real world use", or "I don't feel like making this a single-step install, so if anyone complains I'll just say they care too much about ease of use". In Clojurescript's case it actually seems like the combination of Clojurescript code calling Clojure macros and then being compiled by a compiler written in Clojure and then compiled again with the Closure compiler (aside: this naming is just hilarious) is really complex. There's a lot of mental effort required to say "Hmm, where do I put everything so all the different parts of my project can talk to each other?". A lot of this can be solved in a few different ways: - More mature tooling with sane defaults, so I don't need to know everything a library is doing to use it. The entire point of a tool/abstraction is to take care of this stuff for me. lein-cljsbuild is off to a good start, but as an example: don't make me specify where my .cljs files are when it can `find . -name '.cljs'` and figure it out for most people itself! - Documentation. This is a problem with the Clojure community in general. Auto-generated API docs are worse than useless because they fool developers into thinking they've written actual documentation. Another problem in my own experience is that the performance of all of these extra layers is just awful compared to something lighter weight. If you saw Chris Granger's screencast about the Overtone controller webapp the other day, did you notice that he often had to refresh in the browser a bunch of times before his Clojurescript changes were compiled and took effect? It's a sub-100 line Clojurescript file and yet a several gigahertz machine[3] takes a noticeably long time to show us our changes? We have to mash the refresh button until we're pretty sure our changes have compiled? I really, really want to love Clojurescript, because it's got some beautiful ideas, but it almost seems to have adopted Haskell's "avoid success at all costs" mantra. That's great if you're building an experiment in programming language theory, not so great if you want to save real live people's time and frustration. TL;DR: Clojurescript makes it really complicated to get to a black triangle moment[4] and that's a bad thing. An in-browser version of Clojurescript would reduce the time and effort needed to get there. [1]: http://lesscss.org/ [2]: Yes, I know about lein-cljsbuild. Compare the README at https://github.com/emezeske/lein-cljsbuild to the two lines required to use LessCSS. Yes, this is a matter of easiness, but easy is not a dirty word. [3]: I assume he's using something fairly newish, and my own experience agrees with this. [4]: http://rampantgames.com/blog/2004/10/black-triangle.html
In Bret Victor's live editable game in ClojureScript

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.