38 lines
2.4 KiB
Markdown
38 lines
2.4 KiB
Markdown
# Repository Guidelines
|
|
|
|
## Project Structure & Module Organization
|
|
This repository is a PrestaShop-based store with customizations across core-like folders and modules.
|
|
- `controllers/`, `classes/`, `src/`: main PHP application logic (legacy + Symfony-style code).
|
|
- `modules/`: feature modules (custom and vendor-like). Most front-end build/test tooling lives here.
|
|
- `themes/` and `themes/leo_gstore/`: storefront templates, assets, and theme behavior.
|
|
- `override/`: PrestaShop overrides; keep changes minimal and well-justified.
|
|
- `app/config/`, `config/`: environment and platform configuration.
|
|
- `changelog/`: dated change notes (for example `changelog/2026-03-19.md`).
|
|
|
|
## Build, Test, and Development Commands
|
|
There is no single root build command; use module-scoped workflows.
|
|
- `php -l path\to\file.php`: quick PHP syntax check before commit.
|
|
- `cd modules\ps_facetedsearch && npm install && npm run dev`: install deps and run watch build.
|
|
- `cd modules\ps_facetedsearch && npm run build`: production JS/CSS bundle.
|
|
- `cd modules\ps_facetedsearch && npm test`: run Mocha tests (`tests/**/*.spec.js`).
|
|
- `cd modules\gsitemap && composer install`: install PHP dev dependencies for that module.
|
|
|
|
## Coding Style & Naming Conventions
|
|
- Follow existing PrestaShop conventions: PHP classes in `PascalCase`, methods in `camelCase`, constants in `UPPER_SNAKE_CASE`.
|
|
- Keep indentation/style consistent with surrounding file (legacy files vary; do not reformat unrelated code).
|
|
- Use descriptive module/template names (example: `AdminSearchController.php`, `search-results.tpl`).
|
|
- Prefer changes in `modules/` or `themes/` over editing vendor code in `vendor/` or `phpmailer/`.
|
|
|
|
## Testing Guidelines
|
|
- Test at the smallest valid scope: module-level first, then manual store/admin verification.
|
|
- JS tests use `*.spec.js` (see `modules/ps_facetedsearch/tests`).
|
|
- Run syntax checks for edited PHP files and exercise affected BO/FO pages (cart, product page, checkout, admin config).
|
|
- No global coverage gate is enforced; add/update tests when touching tested modules.
|
|
|
|
## Commit & Pull Request Guidelines
|
|
- Prefer clear, typed commits: `feat: ...`, `fix: ...`, `chore: ...`.
|
|
- Avoid vague messages like `update` or `Save`.
|
|
- Keep commits focused to one concern and include touched paths in PR description.
|
|
- PRs should include: purpose, risk/rollback notes, manual test steps, and screenshots for UI/theme changes.
|
|
- For user-visible behavior changes, add/update a dated file in `changelog/`.
|