Contributing

This page is a short overview. The full guide lives in the repository.

Start with CONTRIBUTING.md

Read CONTRIBUTING.md in the repository first. It is the source of truth for how changes are accepted.

Get set up

1. Build the compiler from source.
2. Make sure the tests run before you change anything. See Running the tests.

The change loop

When you change behavior, run tests in this order:

1. The smallest focused test for what you touched.
2. make test.
3. make test-sanitize, for ownership, runtime, concurrency, FFI, or codegen changes.
4. make test-fixpoint, for frontend, MIR, or compiler changes.

Because Beans is self-hosted, a compiler change has to keep building itself: two release-mode self-builds must stay byte-identical (make test-fixpoint).

Code style basics

Beans’ own code follows the language design rules. A few basics:

• Objects are made with new on a class or a named static, never a free constructor function in a module. See the standard library.
• Packages are snake_case, one directory per package. See Local packages and imports.
• There is no formatter yet, so match the style of the file you are editing.

See the release process for how changes ship.

For the CLI/SQLite pilot tasks, questions for potential users, and steps for another contributor to test the build and release process, see CONTRIBUTING.md. The checklists describe planned work. They do not record completed interviews or retained users.