feature/build-release
claude/smbcloud-github-app-k9641p
development
feature/apps
feature/build-release
feature/ci-docs
feature/ci-ruby-gems
feature/cicd
feature/completion
feature/dist-nuget
feature/fix-ci-sdk-pypi-rubygem
feature/fix-clippy-on-stable-channel
feature/fix-deployment-script
feature/github-email
feature/gresiq-v1
feature/project-new-structure
feature/rsync-deploy
feature/ruby-runner
feature/sdk-npm
feature/sdk-workflows
feature/smbcloud-cli-release-npm
feature/smbcloud-deploy
feature/wasm
main
release/v0.7.4
| 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! |