Modules and imports

Rank programs are organized into modules. Each .rank source file is a module. Modules import from four distinct namespace sources, and project-local code may also use contextual relative anchors for nearby modules.

Namespace sources

Prefix	Source
std::	Official standard library modules and bundled providers
root::	The current project's source tree
package_name::	Installed third-party packages exposing pure Rank modules from local paths, npm registries, or git snapshots
provider_name::	Registered providers from local paths or npm packages, plus any Rank source modules they ship

Import syntax

Named imports bring specific bindings into scope:

use std::collections::{ map, filter, reduce }
use std::object::{ mapValues, keys }
use root::helpers::{ make_url }
use super::types::{ Config }
use self::internal::{ normalize }

Wildcard imports bring all exported bindings into scope:

use std::collections::*
use root::util::*

Named imports are preferred when only a few bindings are needed. Wildcards are useful for namespaces you use heavily.

For project-local modules:

• root::... is the canonical absolute import form
• self::... resolves from the current module namespace
• super::... resolves from the parent namespace and may be chained

self:: and super:: are contextual anchors only when they appear as the leading segment of a qualified module path.

Standard library imports

use std::collections::{ map, filter, flatMap, find, any, all, count }
use std::collections::{ zip, reduce, groupBy, keyBy, sort, sortBy }
use std::list::{ range, flatten, slice, transpose }
use std::object::{ mapValues, keys, values, entries, fromEntries }
use std::Regex::{ matches, search, replace, captures }
use std::Time::{ parse, format, add, diff, minutes }
use std::Path::{ join, from, toString }
use std::Emit
use std::Rand::{ seed, derive, int }

See the Standard library page for full API details.

Project module imports

Source files inside a project's source directory (declared in rank.toml) are accessible under the root:: prefix using their path relative to that directory:

src/
  main.rank
  config/
    defaults.rank
    overrides.rank

// in src/main.rank
use root::config::defaults::{ base_port }
use root::config::overrides::{ production_host }

// in src/config/overrides.rank
use super::defaults::{ base_port }

// in src/config.rank
use self::defaults::{ base_port }

The DAG applies across modules too — the compiler resolves the full cross-module dependency graph and rejects cycles.

Relative anchors are only for project-local modules. Package, provider, and stdlib imports continue to use their ordinary namespace prefixes.

Exports and visibility

Declarations are private by default. Mark a declaration pub to export it:

// in src/config/defaults.rank
base_port = 3000        // private — not importable from other modules

pub api_port = 8080     // exported
pub db_port = 5432      // exported

Imported names are not automatically re-exported. Use top-level named pub use when you want a module to act as a facade:

// in src/billing.rank
pub use self::types::{ Quote }
pub use self::pricing::{ quote }

// in src/main.rank
use root::billing::{ Quote, quote }

Named pub use re-exports the matching public bindings from the target module. If the same spelling exists in both the value and type namespaces, the same pub use surface re-exports both. Wildcard re-exports such as pub use self::types::* are not supported.

Provider imports

Provider namespaces are imported the same way as other modules. The provider must be registered in rank.toml first (see the Provider guide):

use faker::{ Generate, UUID, Int }
use faker::types::{ Spec }

The provider namespace corresponds to the namespace field in the provider's rank.toml.

Project manifest

Every project needs a rank.toml at its root. The source field declares the directory that becomes the root:: module tree:

manifestVersion = 1

[package]
name = "my-project"
version = "0.1.0"
source = "src"

To register a provider:

[providers]
faker = { path = "./providers/faker" }

Dependency aliases in [dependencies] can point at local packages, npm-published packages, or git-backed packages. Provider aliases in [providers] can point at local providers or npm-published provider packages.

For packaging and publishing guidance, see Dependencies and Provider authoring. For the full rank.toml schema, including dependencies, registries, security defaults, and provider-package metadata, see the Manifest Reference.