For the complete documentation index, see llms.txt. This page is also available as Markdown.

Imports and project structure

Imports are relative to the file that contains them.

Import forms

Form
Meaning

import "std:fs"

Package embedded in the compiler

import "./helpers.osl"

One local source file

import "helpers"

Every .osl file directly inside a local directory

import "owner/repository"

Git package installed by Opal

import "go:net/http"

Go package

Directory imports are sorted by filename and are not recursive. Import each child directory explicitly.

A practical layout

Use one top-level entry file and group the rest by responsibility:

src/
  main.osl
  api/
    index.osl
    handlers/
  db/
    users/
      storage.osl
      queries.osl
  helpers/

main.osl should compose the application. Put feature behavior in imported directories. OriginChats uses this layout at production scale: its entry file imports packages, declares shared types and state, imports feature groups, then starts the HTTP and WebSocket servers.

Exports

Without an export statement, a local file exposes all declarations. Add exports to define an explicit public API:

Consumers can merge exports, select names, or create a namespace:

Sibling files in one directory can share private declarations. A consumer in another directory sees only the explicit exports.

Module objects

The expression form returns a local module as an object:

Go modules

Native builds look for go.mod in the entry file's directory and its parents. The compiler copies the selected module files into its generated workspace. A project without go.mod uses a generated module in the OSL cache.

Opal projects

Opal manages Git and Go dependencies, exact lock data, scripts, and package commands. An Opal project uses opal.json, opal.lock, and an ignored .opal/ directory. See Opal projects.

Last updated