Fork me on GitHub
#cljs-dev
<
2017-10-01
>
mhuebert12:10:05

@dnolen some coaches are planning to try teaching w/ the Maria editor at next weekend’s ClojureBridge, it would be nice if CLJS-1576 could make it in, for emoji purposes 🎉. I just rebased the patch: https://dev.clojure.org/jira/secure/attachment/17395/CLJS-1576-2017-rebased.patch

mhuebert13:10:04

@dnolen I’m not sure how frequently these encoded sources are even used, or if they should always be generated. sourcesContent is optional for source-maps and I think tooling usually tries to load original files. it’s possible that :sources-content adds a non-negligible amount of compile time when source-maps are enabled; as far as I can see, it has to run through and base64-encode (+ these string replacements) every source file in the project, but i haven’t timed it. (i think that would be a separate issue, looking at making source-map inlining of sourcesContent optional.)

mfikes13:10:33

I’m fairly certain Planck makes no use of this information (it does source mapping in a slightly different way). And Lumo doesn’t yet have support for source mapping. Perhaps other self-hosted environments use it?

mhuebert14:10:28

I had a really silly bug in my original patch last year which has been live ever since, and never heard a peep about it, so I don’t know if anyone is using it in a meaningful way

mhuebert14:10:18

(although maybe fancy unicode symbols are rare enough that it is being used, but bug never encountered)

mhuebert14:10:51

making it optional might significantly reduce source-map file sizes

dnolen15:10:30

@mhuebert applied to master

thheller15:10:27

you are probably best qualified to answer

juhoteperi15:10:19

We support AMD modules, but I think there is probably no-one using that support

juhoteperi15:10:40

~All npm packages are CommonJS or UMD

thheller15:10:55

I think we always rely on closure doing the correct thing?

thheller15:10:13

AMD is often part of the UMD wrapper, so if the UMD wrapper is still removed we should be fine I guess