This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (19)
- # boot (118)
- # capetown (4)
- # cider (37)
- # cljs-dev (69)
- # cljsjs (23)
- # clojure (212)
- # clojure-austin (10)
- # clojure-india (3)
- # clojure-italy (2)
- # clojure-mke (1)
- # clojure-nl (1)
- # clojure-russia (5)
- # clojure-spec (52)
- # clojure-uk (86)
- # clojurescript (32)
- # core-async (9)
- # cursive (123)
- # datomic (91)
- # emacs (22)
- # events (3)
- # hoplon (68)
- # klipse (4)
- # lambdaisland (10)
- # leiningen (2)
- # off-topic (14)
- # om (14)
- # onyx (44)
- # perun (14)
- # proton (20)
- # re-frame (15)
- # reagent (10)
- # ring-swagger (9)
- # specter (18)
- # untangled (3)
- # yada (4)
@dnolen resuming from twitter: maybe do a sneak peek before it gets out so issues can be ironed out before “it hits the news”?
@dnolen if there’s a git repo with a branch that can be shared here maybe that would be sufficient? I guess it’s all markdown/asciidoc/etc
@martinklepsch cutting a release doesn’t seem necessary if people just want to kick the tires - I also suspect it doesn’t matter what we do there will be lot of fixes enhancements around this stuff
@alexmiller can’t go through it right now - but if you have some time Friday I will ping you :slightly_smiling_face:
Tried the externs stuff in some basic form before, worked great :ok_hand: (not sure if I ever reported back, sorry :)
:smile: I tried pretty basic stuff and the warnings were super helpful + after addressing them the advanced build seemed right IIRC, but again, basic cases...
and actually it demonstrates that the ClojureScript could do a lot more wrt. interop validation
just started investigating CLJS-1901 and the task of inlining source maps
found this interesting condition while reading the code:
is this for historical reason because advanced optimization would render our maps invalid and there was no way to make it work? I think when
:source-map is enabled in opts, we should allow source maps generation in advanced mode as well and let closure compiler to transform it
didn’t read that yet, so the idea is to take closure-produced source map and our (:none-mode) cljs source map and concatenate them in order: cljs-map + closure-map, so that result maps from original cljs sources to optimized result after closure compilation, right?
the Google Closure source map is from every preserved location (DCE removes stuff) to the compiled JS source file location
each original CLJS input to the compiler has an in memory mapping of Loc CLJS-GENJS -> Loc CLJS
there was a naming confusion, by “concatenation" I meant what you mean by “merging" and what closure devs call “composing of source maps” :slightly_smiling_face: 
@darwin ok sorry was confused, usually think about appending when people say concatenation here
I got confused by “merging” because normal clojure map merging clicked in my head :slightly_smiling_face:
gathered some intel here: http://dev.clojure.org/jira/browse/CLJS-1901
It looks promising, I’m going to implement a flag to optionally inline source maps in generated js files using data URLs.
This will fix my original issue but also opens a possibility for closure compiler to read our source maps as input (in all compilation modes).
This would enable:
1. better closure compiler error reporting with source-mapped messages back to original sources
2. complete production of source maps by closure compiler. We could remove
emit-optimized-source-map and rely solely on closure compiler to do the right job. Not sure about backward compatibility. Our compiler flags should map reasonably to closure compiler ones. Also not sure about module splitting and other advanced closure compiler features (yet).
I just wanted make sure that my potential work on inlined source maps won’t be wasted time in the light of recent closure compiler development with source maps support. Also from what I’ve seen implementing inlining in cljs compiler seems easy. So even if it didn’t land it won’t be much wasted effort.
@darwin as long Google Closure can be shown to use the inlined source maps and that the result is as good / better than what we have this is an enhancement I’m all for
this is a bit fishy: https://github.com/clojure/clojurescript/blame/master/src/main/clojure/cljs/compiler.cljc#L1228-L1230 I assume the goal was to get relative path from output-dir to sm-file if the sm-file has output-dir as prefix, or leave it as is otherwise
my concern: this could cause unexpected replacements in sm-file if it happens to repeat output-dir in the path multiple times