Repository navigation
v1.0.2 — Fixtures can pin accepted hazards
This patch release lets a def deliberately author three shapes the engine accepts but 1.0 refused outright: an active cache with ttl: 0, a call passing an input its target does not declare, and a lambda body that does not parse. Each is still flagged by default, and export --strict still fails on it, but a fixture that pins the engine's behavior for that input can now say so.
npm install @xano/sdk@1.0.2cache.ttl of 0 is a warning a def can accept
An active cache whose ttl is not a positive whole number was an export error, so no def could author it, though the engine accepts it and simply never stores. It is now the warning cache.ttl-not-positive, accepted on a query or function with diagnostics: { allow: ["cache.ttl-not-positive"] }.
Passing an input the target does not declare is a warning a def can accept
The engine drops an undeclared input key without a word. statement.unknown-input (on s.function.run, s.api.call, s.middleware.call and the other *.call statements), test.unknown-input (a unit test's input) and db.addon-unknown-input (an attached addon's input) were errors; they are now warnings that the def's diagnostics.allow accepts. Without the allow, --strict still fails them, since a misspelt key is usually a bug.
lam.raw(code, { unchecked: true }) sends a body that does not parse
A body with a syntax error threw while the file loaded, so the engine's answer to one could not be tested. unchecked: true skips the parse check only, both in lam.raw and where the value lands in s.lambda or a fl.* filter. The binding, module-syntax and empty-body checks still apply.
s.lambda({ code: lam.raw("return (1 +;", { surface: "s.lambda", unchecked: true }), as: "result" })Notes
Development dependencies were updated to clear the open brace-expansion security advisories; nothing that ships in the package was affected.