These are chat archives for Gozala/wisp
required modules, not only across files
exports.__wisp_macros__so you could import the macros from someone else's module and use them to transform your own Wisp code
requireas argument from
wispand the inline imports associated with macros into it, but that just makes whole thing a lot more complicated
requirewould pose an issue in browsers? As far as I understand Wisp's
:requirestill depends on there being some kind of platform-provided
requireavailable anyway? As it is, if you're serving multiple separate modules in the browser you would use something like Browserify -- which provides its own
requireshim -- or any of the available in-browser module systems (which I have zero experience with tbh).
:refering a couple of macros here: https://github.com/Gozala/wisp/blob/master/test/protocols.wisp#L2 :D
**macros**as a side effect of importing the module and the
:referis just for show? Or is there something I'm missing here
requrie(‘./util’)it will load util.wisp file and live transpile it
requier, although I had a plan to fix that & I think I wanted to make sure I would not introduce more dependncies that would prevent me from that.
@Gozala I also imagine it should be easy to have an option to toggle including macros (and their dependencies) being included in the compiled output or not? This could be either a compiler option, or per-module and/or per-macro flag (via metadata)... I can certainly see how a Wisp library which is distributed in its compiled form would want to make its macros available without having to recompile the whole library every time
That actually reminded me another idea I had, which was to generate two outputs when file with macro definitions was passed like
module.macros.js so that macro definitions won’t tax the generated js, but would still make it available, alternative would be to let compiler either emit file with macros or file with actual js so you could create two outputs or one.