Thank you for your interest in contributing to Swift Dolibarr! This document provides guidelines to help you get started.
If you find a bug, please open an issue and include:
- A clear description of the problem
- Steps to reproduce the issue
- Expected vs. actual behavior
- The Dolibarr version you are working with
- The Swift and Xcode versions you are using
For feature requests (e.g. support for a new Dolibarr object type), please open an issue first to discuss the idea before submitting code.
- Fork the repository
- Create a branch from
main(e.g.feature/add-bank-account-modelorfix/invoice-decoding) - Make your changes
- Ensure the project builds and any tests pass
- Submit a merge request against
main
This project uses SwiftLint to enforce code style. The linter runs automatically as a build plugin, so any violations will appear as warnings or errors during build.
General guidelines:
- Use 4-space indentation
- Follow Swift naming conventions:
PascalCasefor types,camelCasefor properties and methods - Add doc comments for public API
When adding support for a new Dolibarr object, follow the existing patterns:
- Create a new folder under
Sources/SwiftDolibarr/Models/for the module (if needed) - Inherit from the appropriate base class (
CommonBusinessObject,CommonCommercialTransactionObject, etc.) - Implement
CodingKeysmapping Dolibarr API field names to Swift property names - Implement
init(from:),encode(to:), andhash(into:)following the same structure as existing models - Add statuses to
DolibarrObjectStatusif the object has a status lifecycle - Add the new model to the supported objects table in
README.md
This package is a data model layer only. Contributions should focus on:
- New or updated Dolibarr object models
- Bug fixes in encoding/decoding
- Documentation improvements
Networking, authentication, and API client logic are out of scope for this package.
By contributing, you agree that your contributions will be licensed under the Apache License 2.0.