Kikobeats / isolated-function / 35646340182

97%

push

github

feat: add slot to skip rebuilding a shared program (#81)

* feat: add slot to skip rebuilding a shared program

Callers that wrap many different pieces of code in the same surrounding
program pay a full esbuild bundle on every call, even though only the wrapped
code changes. In Microlink Function, a 661 byte user function was rebuilt into
a 4.4MB bundle on every request, and all but ~100 bytes of it were identical
between requests.

`instance(program, { slot })` builds `program` once with the `SLOT` identifier
still in it, caches the result, and fills the slot per call. The placeholder
is a free identifier, so esbuild keeps it verbatim through bundling and
minification. The filled result is identical to building the filled code
directly.

A cached shell is never reused where it would be wrong for the call: slot code
that requires npm packages, esbuild options that cannot be keyed (plugins),
and a build where SLOT did not survive exactly once all fall back to a normal
build of the filled program. Slot code is parsed as `(${code})`, the form it
takes in the program, so an anonymous function expression is valid and a
syntax error still rejects as a SyntaxError.

The cache is a byte-bounded LRU (`shellCacheBytes`, 32MB by default) because
one shell can be several megabytes. Concurrent calls share one build and a
failed build is not cached. `teardown` clears it.

Measured with the README example: the first call builds in 16.6ms, the
second fills the cached shell in 0.16ms.

Also corrects the docs and types for `profiling.phases`, which described a
`compile` field that the runtime never returned; it reports `install` and
`build`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix: make slot fills independent of how esbuild built the shell

Addresses review on the slot option.

Slot code was spliced into the built shell as source, so what it could see
depended on esbuild: a shell variable only the slot referenced could be
renamed or d... (continued)

196 of 210 branches covered (93.33%)

Branch coverage included in aggregate %.

263 of 263 new or added lines in 3 files covered. (100.0%)

944 of 971 relevant lines covered (97.22%)

34.42 hits per line