Contributing to moonbitlang/core
September 26, 2025 ยท View on GitHub
Step 0: Work with a stable toolchain
Contributions to the core should be based on the latest stable channel of the MoonBit toolchains. Using an unknown or unstable version can confuse reviewers and other contributors with new, potentially incompatible changes.
Therefore, we do not encourage users to submit contributions based on bleeding-edge toolchains. For the latest stable release and installation instructions, contributors can visit https://www.moonbitlang.com/download/.
Step 1: Clone the repository
-
To start working on the project, you need a local copy of the repository. Currently,
moonlooks for moonbitlang/core at~/.moon/lib/core. So, remove it if it exists:rm -rf ~/.moon/lib/core -
Then, use the following command to get the latest version of moonbitlang/core:
git clone https://github.com/moonbitlang/core ~/.moon/lib/core -
Run the following command to bundle moonbitlang/core:
moon bundle --source-dir ~/.moon/lib/core -
If everything goes well, it will generate a bundled core file at
~/.moon/lib/core/target/bundle/core.core. -
Now, you can create a new project and run it to check if everything is working as expected:
moon new hello cd hello echo """fn main { println([1, 2, 3].rev()) }""" > src/main/main.mbt moon run src/main # Output: [3, 2, 1]
Step 2: Make your change
Now it's time to make your changes to the codebase. Whether it's fixing a bug, adding a new feature, or improving documentation, your contributions are welcome. Ensure that your changes are clear and understandable to others who will review your code.
Currently there are some simple restrictions for naming convention and code formatting:
- All function names, method names, and variables should use
snake_case, while all type names should usePascalCase. - The code formatting should align with the result of
moon fmt. - For public functions and types, tests and documentation should be provided.
Step 3: Test your change
After making your changes, it's important to test them to ensure they work as expected and do not introduce new issues. Run the following commands to test your changes:
moon check
moon test
moon fmt
moon bundle
moon info // Generate mbti files, these files should be tracked by git
Step 4: Submit a pull request and request a review
Simply follow the standard GitHub flow to submit your pull request.
After submitting your pull request, request a review from the project maintainers or other contributors.
What kind of contributions are more likely to be accepted
-
Test, documentation and bug fixes
-
Standalone packages with good functionalities, for example, bigint or bigdecimal package
-
Fast and efficient abstractions are preferred over theoretically perfect abstractions
MoonBit is a pragmatic language, we care about both compile time and runtime performance. We don't encourage to add traits for non pervasive abstractions.
-
Large changes are encouraged to communicate earlier before the implementation
The core library is coupled with the compiler to some extent, it is better to communicate your ideas first if you plan to make large structural changes.
-
Testing guidelines
We encourage you to use
inspectoverassertin tests, asinspectprovides more information about the values being tested and can be updated easily. For testing in the loop, you may useassert_since snapshot testing does not work well in the loop. -
New APIs with real meat
We encourage you to add new APIs that are useful and have real meat, rather than just adding APIs for the sake of completeness. If the new API can be composed with existing APIs without loosing efficiency, it is better to use the existing APIs instead of adding new ones, this is due to our current limited bandwidth of the core library.
Naming conventions
- function names,
snake_caseis preferred. - type parameters, one character starting from
Ais preferred, e.g,fn[A,B] Array::map(self : Array[A], f : (A) -> (B)) -> Array[B], for some established conventions,Map[K,V]it is also accepted. - type names,
CamelCaseis preferred.