import / export syntax to share functions, constants, and objects between pages. Create a “module” page with exported code, then import what you need in any other page’s backend script.
Quick example
Create a page (e.g. slugapp) with shared functions:
Import specifier formats
All of these resolve to the same page slugapp:
- The
.jsextension is stripped - Leading
./or../prefixes are stripped - The remaining string is used as the page slug to look up
Named imports
Import specific exports by name:Default imports
Useexport default for a module’s primary export:
Multiple modules
Import from several pages in the same script:Module pages work on their own
A page withexport statements still works when visited directly — the export keywords are silently stripped before execution. This means you can add setVariable calls alongside exports for the module page’s own rendering:
getPlans, only the function is used — the setVariable call in the module runs inside the importing page’s context too (both scripts share the same sandbox).
Supported export syntax
Limits
Supported import shapes
Eachimport line must be either a default import or a named import — not both on the same line:
How imports work
When a backend script containsimport statements:
- Import statements are parsed and removed from the script
- Each module specifier is normalized to a page slug
- The module page’s
<script scope="backend">code is fetched exportkeywords are stripped from the module code, turning exports into regular declarations- The module code is prepended to the importing script
- The combined code runs as a single script in the sandbox
setVariable, session, request, etc.).