Skip to main content
Every Kairo source file belongs to exactly one module. Modules are the primary unit of code organisation and the canonical identity for a piece of code — the filesystem layout is a secondary concern. This page covers the module declaration that names a file’s module, and the import forms you use to bring other modules into scope.

​
module Declaration

The module declaration names the module that a .ak file belongs to. It must appear as the first non-comment line of the file, before any imports or declarations.
Rules:
  • Every .ak file must have exactly one module declaration.
  • The module name is a dot-separated sequence of PascalCase identifiers (e.g., Astra.Data, My.App.Domain).
  • Multiple files in the same directory can share the same module name — the module spans all of them.
  • The module name is the canonical identity of the code. The filesystem path is not authoritative.
Module names are case-sensitive and every segment must be PascalCase. A name like astra.data or Astra.data is invalid.

​
import Declaration

Use import to bring another module into scope. Kairo does not support wildcard imports — you always import a whole module by its full name.
After this import, you can reference any public declaration from Astra.Data using its fully qualified name. Rules:
  • Imports must appear after the module declaration and before any type or function declarations.
  • You can import as many modules as you need, one import per line.
  • There are no wildcard or selective imports — the entire module is imported.

​
import … as Alias

When a module name is long or conflicts with a local name, give it a shorter alias using as.
After this, you refer to the module’s contents through the alias instead of the full module name.
Aliases are especially useful when two modules share a common trailing segment. Giving each a distinct alias keeps your code readable and avoids ambiguity.

​
import type Declaration

Use import type when you need to import only a specific type from a module and want to make that intent explicit. This form is useful when two modules export types with the same name and you need to clarify which one you mean.
Rules:
  • import type imports a single named type, not a whole module.
  • The name after import type is the fully qualified type name.
  • Use this form to resolve ambiguity when multiple imported modules define a type with the same short name.
import type does not replace a full module import. If you also need other declarations from that module, add a separate import line for the module itself.

​
Complete Example

The following file shows all three import forms together.