lib/is the public package surface;lib/lua.dartis the main entry point for consumers.lib/src/holds implementation details: compiler (compiler/), VM runtime (vm/), state and API layers (state/,api/), numeric helpers (number/), binary chunk parsing (binchunk/), and standard libraries (stdlib/).test/contains Dart tests plus Lua fixtures; seetest/stdlib/andtest/module/.example/contains runnable demos (for example,example/example.dart).pubspec.yamldefines SDK constraints and dependencies;CHANGELOG.mdtracks releases.
dart pub getinstalls dependencies for the package.dart run example/example.dartruns the sample program using the Lua VM.dart testruns the full test suite undertest/.dart test test/stdlibruns only the standard library tests.dart analyzeruns static analysis with the default Dart analyzer settings.
- Use standard Dart formatting (
dart format .) with 2-space indentation. - Follow Dart naming conventions:
UpperCamelCasefor types,lowerCamelCasefor variables/functions, andsnake_case.dartfor filenames (e.g.,lua_state.dart). - Keep public APIs in
lib/small and documented; prefer internal helpers underlib/src/.
- Tests use
package:test(seepubspec.yaml). - Name test files
*_test.dartand keep fixtures intest/module/*.luawhen validating module loading or Lua interop. - Add focused unit tests per subsystem (for example,
test/stdlib/string_test.dartfor string library behavior).
- Commit history favors short, imperative summaries without a strict prefix (examples: “release v0.0.5”, “Fix issues10 and normalize the code”, “Update README.md”).
- PRs should include a concise summary, rationale, and test results (e.g.,
dart test). Link related issues and add tests for behavior changes.
- Do not commit secrets or local logs. Keep environment-specific files out of the repo unless required for tests or reproducibility.