Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Allow to fail build when ClojureScript compiler emits warnings #225

jeluard opened this Issue Aug 29, 2013 · 12 comments


None yet
6 participants

jeluard commented Aug 29, 2013

When lein cljsbuild once generates WARNING (via the ClojureScript compiler) the build is considered successful (a green Successfully compiled is printed). The same applies to exception thrown (e.g. when a defn is malformed).

As you can easily miss those it would be nice to have some option to let the build fail and have some corresponding message printed.
An alternative would be to have something similar to lein check for ClojureScript.

This might require changes in ClojureScript compiler as those warnings are directly printed to the output stream there.


cemerick commented Aug 29, 2013

That'd be nice. Yes, this requires upstream support, unless we want to start grepping stdout for WARNINGs. :-P This might take the shape of changing cljs.analyzer/*cljs-warnings* and its consumers to accept e.g. :warn or :error values, rather than simply true and false.

Perhaps @swannodette can comment on the likelihood of the above being accepted?

I'd be ok with optionally converting warnings into errors. I'm also up for somebody thinking through if we should allow these to be collected through some more flexible interface for tools.

lynaghk commented Aug 29, 2013

While we're on the subject of the CLJS compiler; I've been digging through it lately to integrate it with tooling and would absolutely love if we could clean up the APIs so that it was less file/directory/output oriented and instead yielded data (including per-namespace errors/warnings as data).

What's the next step to make that happen: a proposal spec for the compiler interface? A working fork?

@lynaghk a proposal spec would be a good place to start. I'm uncomfortable with the way that tools currently reach into the compiler and into the analyzer, these are bound to churn for the forseeable future. What would be useful is a higher level API that's unlikely to change that hides implementation details. I'm happy to give feedback to anyone who actually wants to lead that charge.

lynaghk commented Aug 29, 2013

I'll take this on and gist something up in the next few days.


cemerick commented Oct 25, 2013

Progress on a stopgap measure percolating here thanks to @sgrove.

zcaudate commented Nov 4, 2013

I'm wondering if this ticket is the reason why builds are now exiting when a file is unable to be processed by the compiler.

Previously, if I made a stupid mistake when running lein cljsbuild auto.. (like missing a bracket), the process will not exit but just throw an error and keep watching files. Now, the program just exits and I have to run it again. Its quite annoying to restart when I am developing... and you can see me struggling trying to do a web demo in the last 2 or 3 minutes because the restarting cljsbuild takes so long... http://www.youtube.com/watch?v=mhBqjJUYY6w

if so, can there be a command like: lein cljsbuild auto-and-keep-going-on-compilation-errors .... or maybe something shorter... though I'd be quite happy to type that out provided the process doesn't exit whenever I miscount my brackets =)


cemerick commented Nov 4, 2013

@zcaudate This is fixed on master and in 1.0.0-SNAPSHOT, see gh-249.

zcaudate commented Nov 4, 2013

Oh awesome! Thank you :)

On 05/11/2013, at 1:04, Chas Emerick notifications@github.com wrote:

@zcaudate This is fixed on master and in 1.0.0-SNAPSHOT, see gh-249.

Reply to this email directly or view it on GitHub.

Has anyone made progress on this? I just got bit by a warning that slipped through into a production build and it broke the app for several customers.

EDIT: just saw that :warning-handlers was added recently. I'll give that a try.


cemerick commented Aug 24, 2015

Yup, the hooks for this exist now in :warning-handlers.

@cemerick cemerick closed this Aug 24, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment