Scripting
Almost every configurator works by swapping between parts you prepared. When a customer can type any width between 40 and 300 centimetres, there is nothing to swap between, and the shape has to be calculated instead.
The Scripting section is where a project connects to a program that does that calculation.
Do you actually need this?
Often not, and it is worth checking before you commit.
If the customer picks from a set of sizes, prepare those sizes as parts and use variants. If the product simply stretches, a parameter binding in the Scene section can drive scale from a slider with no code at all.
Scripting is for when the geometry genuinely changes rather than merely stretching. A shelf unit that gains an extra shelf every 40 cm. A frame whose joints must stay square as it grows. A part cut from a profile the customer uploads.
Where the script comes from
Four options in the source setting.
A linked script project is the normal route. You build the script in the app's Scripts section, publish it, and link it here. It stays maintained in one place and can be shared between projects.
TypeScript written here opens a code editor inside Composer, for a short piece of logic that belongs to this project alone.
A pasted export takes a script exported from the Rete, Blockly or TypeScript editors and drops it in directly.
A public URL loads a script hosted elsewhere, which needs to be served over https and readable by browsers from your store.
Passing the customer's choices in
Your controls are available to the script by their keys, so a slider called width arrives in the script as a value it can use. That is the whole interface: the customer's answers go in, geometry comes out, and the project displays it.
When it runs
You choose the triggers. Once when the scene loads, on every input change, or only when particular controls change.
Be deliberate here, because calculation costs time on your customer's device. A script that rebuilds a complicated assembly on every keystroke of a number field feels sluggish. Naming the specific controls that should trigger it, and letting a debounce absorb rapid changes, keeps it responsive.
There are settings for what the customer sees while it calculates: a spinner, disabled inputs, and how long to wait before showing either. A brief calculation is better left unannounced, while a long one needs a visible indication that something is happening.
Geometry engines
Scripts that do solid modelling need a CAD engine, and you switch on the ones your script uses.
OCCT is the full CAD kernel, for precise solids, filleting and accurate boolean operations. JSCAD and Manifold are lighter alternatives suited to simpler solid combination, with Manifold being a good choice for anything destined to be 3D printed.
Turn on only what you use. Each engine is a substantial download for your customer before your product appears.
Keeping a linked script current
Publishing a script does not change projects already using it. Those keep running the version they were published with, which is deliberate, since a change to shared geometry should not silently alter live products.
When a linked script has moved on, the project page tells you, and republishing picks up the newer version.
Learning to write them
The editors and the geometry library are shared with the wider bitbybit.dev platform, which has far more documentation on them than would fit here, including the full catalogue of operations.