Core Configuration
Prettier Config
Formbricks uses a standardized Prettier configuration defined in@formbricks/config-prettier:
- 110 characters line width
- Double quotes for strings
- ES5 trailing commas
- Always use parentheses for arrow functions
- Strict import ordering
Import Order
All imports follow a strict ordering:- Mocks (for testing)
- Server-only imports
- Third-party modules
- Internal
@formbricks/*modules - Local aliases (`~/*)
- Relative imports
TypeScript Config
- Strict TypeScript checking enabled
- Consistent use of
tsconfig.jsonextending from@formbricks/config-typescript - Example configuration:
JSDoc Comments
Required for public APIs and complex functions:Error Handling
Standardized error handling using the ErrorHandler class:Enforcement Tools
Pre-commit Hooks
Using Husky and lint-staged for automated checks:pnpm lint and the “Run Linters” CI job.
ESLint Configuration
ESLint runs on the flat config format. Every package and app has its owneslint.config.mjs that imports one of the composable tiers exported by @formbricks/eslint-config:
Every tier builds on
@formbricks/eslint-config/base, which holds the shared turbo, prettier, vitest and unused-vars conventions. It exports named building blocks rather than a ready-made config, so packages import one of the tiers above instead of base directly.
Each tier is an array of flat config objects, so a package either re-exports it directly or spreads it and appends its own overrides:
Continuous Integration
- Automated formatting checks in CI/CD pipeline
- SonarCloud integration for code quality analysis
- Coverage requirements for tests
VS Code Integration
Required Extensions
esbenp.prettier-vscode- Prettier formattingdbaeumer.vscode-eslint- ESLint integrationbradlc.vscode-tailwindcss- Tailwind CSS support
Recommended Settings
Best Practices
-
Consistent Formatting
- Always run
pnpm formatbefore committing - Use VS Code’s format on save feature
- Follow the established import order
- Always run
-
Type Safety
- Enable strict TypeScript checks
- Use explicit type annotations when necessary
- Avoid using
anytype
-
Code Organization
- Keep files focused and modular
- Group related functionality
- Use clear, descriptive names
-
Documentation
- Document complex logic
- Use JSDoc for public APIs
- Keep comments current with code changes