chill-bundles/.junie/guidelines.md

Project Guidelines for Junie

Project Overview

Chill is a comprehensive web application built as a set of Symfony bundles. It is a case management system, for social work. The project consists of multiple specialized bundles that provide different functionalities:

• ChillMainBundle: Core bundles that provide the foundation of the application
• ChillPersonBundle: Core bundles that provide the foundation of the bundles associated to person (which is the case for all other bundles)
• ChillCalendarBundle: Calendar and scheduling functionality
• ChillDocStoreBundle and ChillDocGeneratorBundle: Document management and generation
• ChillActivityBundle, ChillEventBundle, ChillTaskBundle: Activity and task tracking
• ChillBudgetBundle: Financial management
• ChillThirdPartyBundle: Integration with external systems
• ChillCustomFieldsBundle: Extensibility through custom fields
• ChillReportBundle: Reporting capabilities
• And several other specialized bundles

Technology Stack

• Backend: PHP 8.3+, Symfony 5.4
• Frontend: JavaScript/TypeScript, Vue.js 3, Bootstrap 5
• Build Tools: Webpack Encore, Yarn
• Database: PostgreSQL with materialized views
• Other Services: Redis, AMQP (RabbitMQ), SMTP

Project Structure

Note: This is a project which exists from a long time ago, and we found multiple structure inside each bundle. When having the choice, the developers should choose the new structure.

The project follows a standard Symfony bundle structure:

• /src/Bundle/: Contains all the Chill bundles. The code is either at the root of the bundle directory, or within a src/ directory (preferred). See psr4 mapping at the root's composer.json.
• each bundle come with his own tests, either in the Tests directory (when the code is directly within the bundle directory (for instance src/Bundle/ChillMainBundle/Tests, src/Bundle/ChillPersonBundle/Tests)), or inside the tests directory, alongside to the src/ sub-directory (example: src/Bundle/ChillWopiBundle/tests) (this is the preferred way).
• /docs/: Contains project documentation

Each bundle typically has the following structure:

• Controller/: Contains controllers
• Entity/: Contains Doctrine entities
• Repository/: Contains Doctrine repositories
• Resources/: Contains views, translations, and public assets
• DependencyInjection/: Contains service configuration
• Export/: Contains services related to exports
• Security/: Contains services related to security. Most of the time, those are new voters, and so on.

Development Guidelines

Building the Project

Before submitting any changes, you should build the project to ensure that all assets are properly compiled:

yarn run encore production

For development with hot-reloading:

yarn run encore dev --watch

Testing

The project uses PHPUnit for testing. Each bundle has its own test suite, and there's also a global test suite at the root level. When making changes, you should run the relevant tests to ensure that your changes don't break existing functionality.

The tests are run globally, but each bundle is within a test suite.

# to run test for a bundle "Name":
vendor/bin/phpunit --testsuite NameBundle

Code Style

The project uses ESLint for JavaScript/TypeScript code quality. You can run the linter with:

yarn run eslint

For PHP, we use three tools:

• php-cs-fixer, that we can run using globally installed php-cs-fixer command;
• phpstan, that we can run using vendor/bin/phpstan. We use level phpstan level 5.
• rector, that we can run using vendor/bin/rector.

Deployment

The project can be deployed in a production environment following Symfony's deployment guidelines. The documentation provides detailed instructions for setting up a production environment.

Documentation

Comprehensive documentation is available in the /docs/ directory, including installation instructions, configuration guides, and operational procedures.

Conclusion

When working with this project, Junie should:

1. Understand the modular bundle structure and how the different components interact
2. Build the project before submitting changes to ensure assets are properly compiled
3. Run relevant tests to ensure changes don't break existing functionality
4. Follow the established code style and patterns