Skip to main content

TypeScript

This page covers advanced options for writing serverless functions in TypeScript.

Upgrade​

Since your project includes all Satellite features, it's essential to stay in sync with Juno’s updates to maintain compatibility.

Always check the releases page for the latest changes, and update your local container image (source repo) accordingly to ensure you're running the latest runtime and features.

Important

If your Satellite includes custom serverless functions, do not upgrade through the Juno Console. The Console upgrade replaces your Satellite with the stock version, which would overwrite your custom code.

When the Console notifies you of a new version, use it as a reminder to update your dependencies and redeploy your custom build, as described below.

What to do​

The most important step is to keep your local Docker image up to date by pulling the latest version. The entire toolchain is shipped within the emulator, so you don't have to install additional tools on your machine, but it also means the image needs to stay current.

Check the releases page to know when a new image is available.

If a release also includes updates to the JavaScript library, bump the relevant package in your project accordingly.

If you deploy with GitHub Actions, your workflow always inherits the latest image, so triggering a new CI run is enough to stay up to date, unless you have pinned a specific action version, in which case update it to latest.

caution

Always upgrade iteratively and avoid skipping version numbers. While we strive to minimize breaking changes, it's crucial to upgrade through each released version sequentially.

For example, if you're on v0.0.23 and the latest release is v0.0.26, first upgrade to v0.0.24, then v0.0.25, and finally v0.0.26. Skipping versions could lead to unexpected issues.

Versioning​

When writing serverless functions in TypeScript, Juno uses the version defined in your project’s package.json. This version is embedded into the compiled Wasm module and shown in the Juno Console, making it easier to keep track of deployments.

By default, the version is inherited from the root-level version field:

{
  "name": "demo",
  "version": "0.0.10"
}

However, if you want to version your functions independently from your app or workspace, you can define a custom version field specifically for Juno Functions:

{
  "name": "demo",
  "version": "0.0.10",
  "juno": {
    "functions": {
      "version": "0.0.4"
    }
  }
}

This version is embedded into the compiled Wasm binary and displayed in the Juno Console. It helps you:

  • Track which version of your serverless logic is currently deployed.
  • Debug more effectively by matching behavior in the Console with specific code versions.
  • Move independently of Juno updates — you're in full control of your own function versioning.

You can use any versioning scheme that suits your development workflow (e.g. 0.1.0, 1.0.0-beta, 2025.04.18...).