Scripts — batteries and their boundary

A script is logic over what the node hands it. This page maps what a script author is likely to want onto where it comes from — the release, a library, a service, a release of your own — and states the test that decides when the node itself grows. The contract a script implements and the calls it may rely on across releases are documented once, at YmerNode.Script (What a script may call) and YmerNode.Script.Context; this page points there and never restates them. A promised package's own documentation is one call away in a session — scripts info <name> renders it from the release at the version it carries. Terms: script, battery, declaration, files directory.

The boundary

In scope: reaching another system and moving or transforming data — read what it holds into a shape a worker can use, write what a worker produced into the shape the system accepts. A periodic report compiled from any data the user points at is in scope; so is a browser-driven test of a web UI.

Out of scope: serving. The node has no user-facing listener and a script gets none. A script compiles and pushes its output to a host; it never hosts. A framework that exists to serve — a web server, a UI — is the shape that is too large for a script.

Where a capability comes from

Five rungs, tried in order. A request for "libraries X and Y" is answered by the first rung that fits.

1. The release already has it. Elixir's and Erlang/OTP's standard libraries reach further than most authors expect: EEx templating, :zip, :erl_tar and :zlib, :crypto and :public_key (hashing, HMAC, signatures), Date and DateTime, File and Path. One caveat: a release ships only the OTP applications its dependencies need, so an OTP application outside that set — :ssh as of this writing — is absent until a use case adds it.

2. A library. Shared Elixir code authored like a script and declared by the scripts that use it: the home for anything expressible in Elixir at the size of a module or a few — a converter, a client, a protocol.

3. A service over HTTP. The node is an integration host, so a capability that exists as a service is reached the way any system is: a PDF renderer, a browser, an LLM or embedding API. No battery, and often the better operational shape.

4. A release of your own. The node is open source, and an application that runs it builds its own release. An organisation with a native need the node does not carry adds the dependency to its own release; the script contract is unchanged. The promise in YmerNode.Script covers the packages ymer_node itself depends on only.

5. A battery. The node itself grows, through its roadmap, when a use case in hand needs something no library can be:

   • native code — a compiled extension the running node cannot build from a script's text;
   • a node-owned process or configuration — a throttle shared by several scripts, a token cache, a connection pool;
   • a package a library would only vendor — thousands of lines with their own upkeep;
   • a format so common that every integration host is expected to speak it, where a good library exists. Forcing every author to replicate a good library the release could carry is waste; the bar is ubiquity plus a good library, never a good library alone. Parquet is the counter-example — cool, but a much less used format with no direct use case here, so not defensible.

   A use case in hand, never a category, for the first three reasons: a battery joins for a script someone is writing. The fourth names its own use case — every integration host's.

The survey

What script authors on comparable platforms reach for — the classes are those of Google Apps Script's services, n8n's core nodes and Huginn's agents — and where each lands here.