- Format:
gleam format - Type check only:
gleam check - Test:
gleam test - Build and validate:
gleam build - Install a package:
gleam add <package_name> - Generate docs:
gleam docs build
Use gleam build as the default post-edit validation command in this repository. Use gleam check only when you explicitly want a quick type check without generating build artifacts.
- The root package is a library and does not provide a default
gleam runentrypoint. - To run an executable module, use
gleam run -m <module_name>. - Projects under
examples/are separate Gleam projects. Run their commands from each project's root directory, such asexamples/kitazith_example.
- Prefer standard library functions or well-established third-party libraries when possible.
- Check the standard library and official package documentation before implementing.
- Avoid reinventing the wheel.
- Labelled arguments are available.
- Prefer preposition-style labels such as
in,each,with,from,to,over, andapplywhen they make calls read like natural English. - Example:
replace(in: "A,B,C", each: ",", with: " ") - Due to language constraints, positional arguments must come before labelled arguments.
- Labels are optional, and callers may omit them.
- Prefer qualified imports for functions, such as
list.map. Unqualified function imports are discouraged. - For types whose name matches the module name, unqualified type imports are conventional.
- Example:
import gleam/option.{type Option}.
- Test files must be located in the
testdirectory. gleeunittest modules should use the_test.gleamsuffix.- Test functions should use the
_testsuffix.
- Run
gleam formatafter every code change in the package you edited. - Run
gleam buildafter every code change in the package you edited. Treat warnings as errors and fix issues such as unused imports immediately. - Run
gleam testafter adding or changing functionality in the package you edited. - If you edit files under
examples/, run validation commands from the root directory of the example project you edited.