Fork me on GitHub

@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:


@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.)


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?


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


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


making it optional might significantly reduce source-map file sizes


@mhuebert applied to master


you are probably best qualified to answer


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


~All npm packages are CommonJS or UMD


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


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