|
| 1 | +--- |
| 2 | +description: Common rules for using Cursor AI Code Editor in Wunder Drupal projects |
| 3 | +globs: |
| 4 | +alwaysApply: true |
| 5 | +--- |
| 6 | + |
| 7 | +# Common rules for using Cursor AI Code Editor in Wunder Drupal projects |
| 8 | + |
| 9 | +## File Organization |
| 10 | +- Keep all rule files in @.cursor/rules/ directory |
| 11 | +- Use .mdc extension for rule files |
| 12 | +- Name files descriptively (e.g., common.mdc) |
| 13 | +- Each rule file should focus on a specific component or feature |
| 14 | +- Use @.cursorindexingignore to exclude files from Cursor's indexing: |
| 15 | + - Database dumps and large binary files |
| 16 | + - Environment-specific configuration files |
| 17 | + - Drupal's generated files and directories |
| 18 | + - Vendor directories and dependencies |
| 19 | + - Temporary files, logs, and cache files |
| 20 | + - Sensitive deployment files: |
| 21 | + - silta/*.secrets |
| 22 | + |
| 23 | +## Key Project Files |
| 24 | +- **Configuration & Setup** |
| 25 | + - @.lando.yml - Local development environment configuration (Lando) |
| 26 | + - @.ddev/config.yaml - Local development environment configuration (DDEV) |
| 27 | + - @composer.json - PHP dependencies and project configuration |
| 28 | + - @README.md - Project documentation and setup instructions |
| 29 | + - @.env.example - Example environment variables template |
| 30 | + - @phpstan.neon - PHP Static Analysis configuration |
| 31 | + - @phpcs.xml - PHP Code Sniffer ruleset |
| 32 | + - @grumphp.yml - Git hooks and code quality checks |
| 33 | + |
| 34 | +- **Deployment & CI/CD** |
| 35 | + - @.circleci/config.yml - CircleCI configuration for CI/CD pipelines |
| 36 | + - @silta/silta.yml - Kubernetes deployment configuration |
| 37 | + - @silta/silta-main.yml - Main environment specific configuration |
| 38 | + - @silta/silta-prod.yml - Production environment specific configuration |
| 39 | + |
| 40 | +- **Utilities & Scripts** |
| 41 | + - @scripts/syncdb.sh - Database synchronization tool (supports both DDEV and Lando) |
| 42 | + - @.lando/xdebug.sh - Xdebug configuration script for Lando |
| 43 | + - DDEV commands: |
| 44 | + - `ddev start` - Start the development environment |
| 45 | + - `ddev composer install` - Install PHP dependencies |
| 46 | + - `ddev drush` - Run Drush commands |
| 47 | + - `ddev xdebug` - Configure Xdebug |
| 48 | + |
| 49 | +- **Drupal Specific** |
| 50 | + - @web/sites/default/settings.php - Drupal settings |
| 51 | + - @drush/ - Drush commands and configuration |
| 52 | + |
| 53 | +## Documentation |
| 54 | +- Use markdown for documentation |
| 55 | +- Reference files with @ prefix for better IDE integration |
| 56 | +- Document dependencies and versions |
| 57 | +- Note breaking changes |
| 58 | +- Include future considerations |
| 59 | +- Keep documentation up to date with code changes, especially @README.md |
| 60 | +- Document version constraints and requirements |
| 61 | +- Keep Cursor code functionality related rules up to date with code changes (@.cursor/rules/*.mdc) |
| 62 | +- Reference specific rules when applicable, see: @.cursor/rules/ |
| 63 | +- When proposing code changes, always include a git commit message following the format defined in Git Commits section |
| 64 | + |
| 65 | +## Git Commits |
| 66 | +Prefix commit message with JIRA ticket number from branch name, following [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification. |
| 67 | +Format commit messages using the following types: |
| 68 | + |
| 69 | +- feat: New feature (correlates with MINOR in semantic versioning) |
| 70 | +- fix: Bug fix (correlates with PATCH in semantic versioning) |
| 71 | +- docs: Documentation changes |
| 72 | +- style: Changes that do not affect the meaning of the code |
| 73 | +- refactor: Code changes that neither fix a bug nor add a feature |
| 74 | +- perf: Performance improvements |
| 75 | +- test: Adding missing tests or correcting existing tests |
| 76 | +- build: Changes that affect the build system or external dependencies |
| 77 | +- ci: Changes to CI configuration files and scripts |
| 78 | +- chore: Other changes that don't modify src or test files |
| 79 | + |
| 80 | +Breaking changes must be indicated by appending a ! after the type/scope or including "BREAKING CHANGE:" in the footer. |
| 81 | + |
| 82 | +When providing commit messages, always use Cursor's code block feature (the code block button in the editor or triple backticks in markdown). This creates a copyable code block with the "Copy" button that allows for one-click copying with exact formatting including hyphens. Always provide just the commit message itself without any surrounding explanations: |
| 83 | + |
| 84 | +``` |
| 85 | +QAG-xxxx: (type) Concise description of changes |
| 86 | + |
| 87 | +- First change detail with hyphen for GitHub markdown compatibility |
| 88 | +- Second change detail |
| 89 | +- Third change detail |
| 90 | + |
| 91 | +Refs: file1.ext, file2.ext |
| 92 | +``` |
| 93 | + |
| 94 | +### Git Diff for Commit Messages |
| 95 | +When creating commit messages, always analyze the actual changes using `git diff` for the specific file(s) modified: |
| 96 | + |
| 97 | +- **Use `git diff --staged | cat` as the default approach** to see all staged changes. This ensures you capture all modifications intended for the commit. |
| 98 | +- Use `git diff <filename>` to see specific changes to a file |
| 99 | +- Review the diff output to identify: |
| 100 | + - What functionality was added, modified, or removed |
| 101 | + - Which files were affected |
| 102 | + - The scope and impact of the changes |
| 103 | +- Ensure commit message bullet points accurately reflect the changes visible in the diff |
| 104 | +- Be specific about what changed and why, based on the actual code modifications |
| 105 | + |
| 106 | +## Development Environment |
| 107 | + |
| 108 | +### Code Standards |
| 109 | +- PHP version: 8.3+ (as specified in @composer.json) |
| 110 | +- Follow Drupal coding standards (defined in @phpcs.xml) |
| 111 | +- Follow PHP Static Analysis rules (defined in @phpstan.neon) |
| 112 | +- Use GrumPHP for enforcing code quality standards (@grumphp.yml) |
| 113 | +- Group related changes by component |
| 114 | +- Use consistent naming conventions |
| 115 | +- Comment complex logic |
| 116 | +- Consider backward compatibility |
| 117 | + |
| 118 | +### Technology Stack |
| 119 | +- **Core Technologies** |
| 120 | + - Drupal |
| 121 | + - PHP via Nginx |
| 122 | + - MariaDB |
| 123 | + |
| 124 | +- **Development Tools** |
| 125 | + - Xdebug |
| 126 | + - PHPStan |
| 127 | + - PHPCS/PHPCBF with WunderDrupal and WunderSecurity rulesets |
| 128 | + - GrumPHP for Git hooks |
| 129 | + - Composer for PHP dependencies |
| 130 | + - NPM for front-end assets |
| 131 | + |
| 132 | +- **Infrastructure** |
| 133 | + - DDEV for local development (containerized environment with Nginx, PHP, MariaDB) |
| 134 | + - Additional services: Adminer, Elasticsearch, Kibana, Mailpit, Varnish |
| 135 | + - Configuration in @.ddev/config.yaml and related service files |
| 136 | + - Lando for local development (containerized environment with Nginx, PHP, MariaDB) |
| 137 | + - Additional services: Adminer, Elasticsearch, Kibana, Mailpit, Varnish |
| 138 | + - Configuration in @.lando.yml |
| 139 | + - Silta deployment system (Wunder's Kubernetes deployment solution) [@wunderio/silta](https://github.com/wunderio/silta) |
| 140 | + - Helm charts for Kubernetes orchestration |
| 141 | + - Docker containerization (Nginx and PHP containers) |
| 142 | + - Google Cloud Platform (GCP) infrastructure |
| 143 | + - Kubernetes-based autoscaling (2-10 replicas in production) |
| 144 | + - Varnish caching (configurable) |
| 145 | + - CircleCI for continuous integration |
0 commit comments