This is the standard library for MoonBit.
-
MoonBit code is organized in block style, each block is separated by
///|, the order of each block is irrelevant. In some refactorings, you can process block by block independently. -
Try to keep deprecated blocks in file called
deprecated.mbtin each directory. -
moon fmtis used to format your code properly. -
moon infois used to update the generated interface of the package, each package has a generated interface file.mbti, it is a brief formal description of the package. If nothing in.mbtichanges, this means your change does not bring the visible changes to the external package users, it is typically a safe refactoring. -
So in the last step, you typically run
moon info && moon fmtto update the interface and format the code. You also check the diffs of.mbtifile to see if the changes are expected. -
You should run
moon testto check the test is passed. MoonBit supports snapshot testing, so in some cases, your changes indeed change the behavior of the code, you should runmoon test --updateto update the snapshot. -
You can run
moon checkto check the code is linted correctly. -
MoonBit packages are organized per directory, for each directory, there is a
package.jsonfile listing its dependencies. Each package has its files and blackbox test files (common, ending in_test.mbt) and whitebox test files (ending in_wbtest.mbt). -
In the toplevel directory, this is a
moon.mod.jsonfile listing about the module and some meta information. -
When writing tests, you are encouraged to use
inspectand runmoon test --updateto update the snapshots, only use assertions likeassert_eqwhen you are in some loops where each snapshot may vary. You can usemoon coverage analyze > uncovered.logto see which parts of your code are not covered by tests. -
agent-todo.md has some small tasks that are easy for AI to pick up, agent is welcome to finish the tasks and check the box when you are done