Update BrowserEnv to include inline sourcemaps

[xeqi]

Also dissoc :source-map from the cljsc/build call as newer cljs version require :output-dir to line up correctly with other flags when it is there, and do we really need sourcemaps for the client-js?

Probably also want to up the version numbers in project.clj based on cljs w/ inline sourcemaps and piggieback updates.

[cemerick]

Straightforward. Q: should source-maps really be on by default?

[xeqi]

A: Yes. It would be consistent with the built-in cljs repl https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/repl/browser.clj#L251, Additionally, it is the default that presents better line numbers for errors, logging, and (hopefully) debugging info.

[cemerick]

Heh, OK. But, are there any costs that I / users should be aware of? Assume that I know jack about source maps, which happens to be true. :-)

[xeqi]

Background:

Source maps only work in a browser repl. The changes do not effect other repl environments. In order to have source maps work the user needs to have enabled them in the browser and the proper map information needs to be sent from the server.

There have been changes made in the clojurescript compiler to make evaluate-form send an "inline" version of this map information. Then only one request is sent containing the compiled javascript to evaluate. The browser reads it, finds the inline source information, and creates the cached version of the javascript, sourcemap, and "file" representing the evaluated form.

Advantages:

In functions that are defined through the repl, (.log js/console ...) and (.error js/console ...) will present the line numbers and links to the .cljs file representing the repl form. Browser debugging should be able to be done from the .cljs file (though this may require some additional work on sourcemap info in the clojurescript compiler to have work really well).

This names the .js and .cljs files, so they show up time stamped in chrome's sources list.

The client part of the repl uses javascript's eval to run the compiled code. This change also "names the eval", presenting line numbers for errors and log statements performed as top level forms in the repl.

Costs:

Creating the source map information probably causes some overhead on js generation. The browser reading the source information probably has some overhead. I have not found it to be noticeable, even when sending entire files through piggieback.

Getting to the compiled javascript is slightly harder for a user, as errors and such point to .cljs. However, all the files (even the js) show up under chrome's sources list.

One possible ugly situation:

Assume a user has sourcemaps enabled in the browser, does not have sourcemaps enabled in lein-cljsbuild, and is happy traversing compiled javascript for line numbers. Defaulting to generating sourcemap information for the repl will instead present them with .cljs instead of .js for the repl forms. This could be solved by either turning off source maps in the browser or explicitly turning them off for the repl.

I consider this situation to be less likely then someone having sourcemaps enabled and wanting .cljs information. I would rather make the .js workflow require (repl-env {:source-maps false}), and have the default environment be as cljs helpful as possible.

[cemerick]

I appreciate the writeup. :-)

I now see individual .cljs sources in chrome containing each evaluated expression, so it looks like this is working. Thanks!

Now available as [com.cemerick/austin "0.1.4-SNAPSHOT"], will cut a real release this coming week.