It is not uncommon for workbooks to reinvent the wheel with formulas or VBA - someone needs WORKDAYS_BETWEEN, someone else needs GEOMETRIC_MEAN, a third person needs to strip non-numeric characters from a column of account codes. These are obvious, common, useful things. They get implemented quietly, slightly differently, in every project, and then never shared. Custom functions are a natural fix for this: write it once properly, ship it as part of the add-in, and every user gets the same tested implementation.
That’s a huge advantage of the add-in model that is easy to miss.
The xllify standard library is currently 47 functions across eight categories - dates, financials, maths, text, lookups, validation, logic, conversion - that you can include in any add-in build without writing them yourself. Open source on GitHub.
Why this exists
The xllify Assistant generates Luau from plain English. It does an admirable job, and a grounded stdlib makes it better: instead of generating bespoke logic from scratch each time, the model can delegate to known, tested functions. That means deterministic output, no hallucinated function names, reuse of code that has already been proven in production, and faster generation because the hard parts are already solved. A real, versioned stdlib gives the model something concrete to work from - and gives you something to check against. If it isn’t in there, it doesn’t exist.
Performance matters too. All stdlib functions are thread-safe and run across xllify’s worker pool, so large ranges parallelise automatically. Where it makes sense, heavy lifting is delegated to native code rather than pure Luau.
Using it
The stdlib is modular - take what you need and add it to your build line:
xllify build xll -o my-addin.xll functions/my-funcs.luau stdlib/lib/text/extract_domain.luau
Or simply copy what you need from stdlib into functions.
Functions are registered alongside your own, under whatever namespace you’ve set in xllify.json.
What it looks like
Take STRIP_NON_NUMERIC from the text category - something you’d otherwise implement four slightly different ways across four different workbooks:
xllify.ExcelFunction({
name = "STRIP_NON_NUMERIC",
description = "Removes everything except digits, dot, and minus sign",
category = "xllify.text",
parameters = {
{ name = "text", type = "string", description = "The text to clean" }
}
}, function(text)
if type(text) ~= "string" then text = tostring(text) end
return text:gsub("[^%d%.%-]", "")
end)
=STRIP_NON_NUMERIC("$1,234.56") returns "1234.56". Three lines. Done.
Some functions delegate heavier work to native code built into the runtime. LEVENSHTEIN is a good example - the edit distance algorithm in pure Luau would be a nested loop with a table allocation per call, which gets slow over large ranges. Instead:
xllify.ExcelFunction({
name = "LEVENSHTEIN",
description = "Returns the edit distance between two strings",
category = "xllify.text",
parameters = {
{ name = "a", type = "string", description = "First string" },
{ name = "b", type = "string", description = "Second string" }
}
}, xllify.levenshtein_distance)
xllify.levenshtein_distance is a utility built into the runtime - implemented in C++, exposed to Luau, no reimplementation needed. Passing it directly handles registration and the native call does the work. Applied to a column of a thousand strings it’s fast enough that you won’t notice.
You can view the full list of built-ins at https://xllify.com/stdlib#cat-builtins. Minimal at the moment, lots planned.
Contributing
Pull requests are welcome. The bar is straightforward: does it not already exist in Excel? Is it useful across more than one domain? If yes, it probably belongs here.