This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-24
Channels
- # 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 (31)
- # 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)
- # vim (26)
- # 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”?
@martinklepsch there’s not a great way to do that with the website far as I know?
@alexmiller do we have staging place for the ClojureScript website?
@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
https://github.com/clojure/clojurescript-site/blob/js-modules/content/guides/javascript-modules.adoc
https://github.com/clojure/clojurescript-site/blob/externs/content/guides/externs.adoc
was just looking for that repo 🙂
We do have staging, but it's not public
I can walk you through it though @dnolen if needed
@alexmiller can’t go through it right now - but if you have some time Friday I will ping you 🙂
Cool, staging not needed I guess.
Now is fine
ping @roman01la — might be of interest to you as well
@martinklepsch the Externs guide assumes Quick Start
@dnolen I’ll check the links and give it a shot tomorrow
Tried the externs stuff in some basic form before, worked great 👌 (not sure if I ever reported back, sorry :)
@martinklepsch heh, it was actually pretty broken 🙂
😄 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
sounds exciting! loving the docs as well 🙂
just started investigating CLJS-1901 and the task of inlining source maps
found this interesting condition while reading the code:
https://github.com/clojure/clojurescript/blob/960bb9b778190aa7359acb2f74cc61d452cef2ae/src/main/clojure/cljs/compiler.cljc#L1315
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” 🙂 [1]
looking into —source_map_input
flag
[1] https://github.com/google/closure-compiler/pull/2129#issue-187494266
@darwin ok sorry was confused, usually think about appending when people say concatenation here
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[1] 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).
[1] https://github.com/binaryage/dirac/blob/master/docs/node.md#source-maps
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