1 file changed
+113
CONTRIBUTING.md
new
+113
@@ -0,0 +1,113 @@
1
+# Contributing to smbcloud-cli
2
+
3
+Thank you for considering contributing to smbcloud-cli! This document outlines the process for contributing to this project.
4
+
5
+## Code of Conduct
6
+
7
+By participating in this project, you agree to abide by our Code of Conduct. Please be respectful and considerate of others.
8
+
9
+## Getting Started
10
+
11
+### Prerequisites
12
+
13
+- Git
14
+- Node.js (recommended version: 14.x or later)
15
+- npm or yarn
16
+
17
+### Setting up your development environment
18
+
19
+1. Fork the repository on GitHub
20
+2. Clone your fork locally:
21
+ ```
22
+ git clone https://github.com/your-username/smbcloud-cli.git
23
+ cd smbcloud-cli
24
+ ```
25
+3. Install dependencies:
26
+ ```
27
+ npm install
28
+ ```
29
+ or if you use yarn:
30
+ ```
31
+ yarn install
32
+ ```
33
+4. Create a branch for your work:
34
+ ```
35
+ git checkout -b feature/your-feature-name
36
+ ```
37
+
38
+## Development Workflow
39
+
40
+1. Make your changes in your feature branch
41
+2. Add tests for your changes
42
+3. Ensure all tests pass with `npm test`
43
+4. Ensure your code follows the style guidelines with `npm run lint`
44
+5. Commit your changes (see Commit Message Guidelines below)
45
+6. Push to your fork and submit a pull request
46
+
47
+### Commit Message Guidelines
48
+
49
+We follow conventional commit messages. Each commit message should consist of:
50
+
51
+- **type**: What kind of change is this?
52
+ - `feat`: A new feature
53
+ - `fix`: A bug fix
54
+ - `docs`: Documentation changes
55
+ - `style`: Code style changes (formatting, missing semicolons, etc)
56
+ - `refactor`: Code changes that neither fix bugs nor add features
57
+ - `perf`: Performance improvements
58
+ - `test`: Adding or updating tests
59
+ - `chore`: Changes to build process or auxiliary tools
60
+
61
+Example:
62
+```
63
+feat: add command to list SMB shares
64
+```
65
+
66
+## Pull Request Process
67
+
68
+1. Update the README.md or documentation with details of your changes, if appropriate
69
+2. Ensure your code passes all tests and linting
70
+3. The PR should address a single concern and be reasonably sized
71
+4. A project maintainer will review your changes and may request modifications
72
+5. Once approved, your PR will be merged
73
+
74
+## Testing
75
+
76
+- All new features should include appropriate tests
77
+- Run the existing test suite with `npm test` to ensure your changes don't break existing functionality
78
+- For testing CLI commands, consider using a tool like [commander](https://github.com/tj/commander.js/) or [oclif](https://oclif.io/)
79
+
80
+## Style Guide
81
+
82
+- We use ESLint to enforce code style
83
+- Run `npm run lint` to check your code
84
+- Ideally, configure your editor to show ESLint errors/warnings
85
+
86
+## Issue Reporting
87
+
88
+- Use the GitHub issue tracker to report bugs or suggest features
89
+- For bugs, please include:
90
+ - A clear description of the issue
91
+ - Steps to reproduce
92
+ - Expected behavior
93
+ - Actual behavior
94
+ - Your environment details (OS, Node.js version, etc.)
95
+- For feature requests, please include:
96
+ - A clear description of the feature
97
+ - Any relevant examples or use cases
98
+
99
+## Documentation
100
+
101
+- Keep documentation up to date as you make changes
102
+- Document all public APIs and CLI commands
103
+- Update the README.md if adding new features or changing existing behavior
104
+
105
+## Releasing
106
+
107
+Project maintainers will handle the release process. Generally, we follow semantic versioning (MAJOR.MINOR.PATCH).
108
+
109
+## Questions?
110
+
111
+If you have any questions about contributing, please reach out to the project maintainers through GitHub issues.
112
+
113
+Thank you for your contributions!