Hi,
AFAIK QuickJS has no bug regarding your point (2). Imported variables in
a module are "live" read-only bindings which can be modified only by the
module defining them.
Adding something similar to atexit() would be possible of course.
Regarding Typescript, it would be simpler to just invoke it before
running qjs with a script. But you lose one great advantage of QuickJS
i.e. its compilation speed !
Best regards,
Fabrice.
On 9/16/19 5:13 PM, Steven Degutis wrote:
Hi everyone. I have five short things to mention. I’m not sure any of
them are big enough to deserve their own thread, but I don’t know
mailing list etiquette well enough, so if this is an infraction of that
then please pardon me and let me know how this could be done better in
the future :)
1. I’ve been working on an escape code library, because QuickJS is
perfect for writing CLIs due to its quick startup time, small runtime,
and ability to make executables. I only have macOS with Apple Terminal
to test it on, but it works great. If anyone’s interested, it’s
at: https://github.com/sdegutis/committer/tree/master/r3k
2. I’m pretty sure the ES standard says that exported “let” variables
should be considered “live bindings”, so that if another module imports
it and *reassigns it*, the module that exported it will also see the new
variable. I tried to use this feature in my lib but it doesn’t work in
QuickJS. Not an urgently needed feature on my part, but thought I should
mention it in case it’s not a known bug, or maybe I’m wrong and it’s not
a bug at all.
3. Does anyone have TypeScript definitions for the “std” and “os”
modules? I was trying to create them myself, but I got stuck on a few
things, and thought I’d check to see if anyone else made one first
before potentially spending time on a solved problem.
4. Will/should there be an atexit() or onexit() callback? I don’t know C
well enough to offer an implementation myself, but I think it would be a
useful addition and probably not too hard. For now I just made my API
recommend calling a cleanup function before exit, but it’d be nice if my
lib could do that for the user instead. The main problem with this would
be if multiple libs want to do that, then they’d have to all make sure
to capture the existing callback and call that first, but shouldn’t be
difficult with some coordination.
5. I’m really interested in writing my modules in pure TypeScript, which
kind of implies wrapping the TypeScript compiler around qjs (and maybe
calling it qts). I was going to try my hand at this as a thing purely
external to QuickJS, but the main problem is that imports would have to
be made aware that they have to transform TypeScript into JS before
interpreting it via the normal QuickJS mechanisms. Does QuickJS’s C API
allow overriding or wrapping the behavior of “import” to make this
happen? That might be a way to solve this. If not, is it something the
API can add? Or maybe TypeScript is special-cased (exceptional) enough
that QuickJS could support this behavior natively, maybe if it imports
or runs a file ending in ‘.ts’?
Thanks again Fabrice and Charlie for a great project, and everyone else
here for helping make it even better.
-Steven
