Linting and Code Style

Relevant source files

The following files were used as context for generating this wiki page:

• eslint.config.js
• commitlint.config.js
• packages/eslint-config/base.js
• package.json
• packages/eslint-config/react.js
• turbo.json

The adfluens-app project employs a comprehensive and automated system for maintaining code quality, consistency, and adherence to best practices. This is achieved through a combination of ESLint for static code analysis, Prettier for code formatting, and Commitlint for enforcing conventional commit message standards. The entire system is orchestrated within a Turborepo monorepo, leveraging shared configurations and automated scripts to ensure a consistent developer experience across all packages and applications.

This system is designed to catch errors and style issues early, automate formatting to reduce cognitive load, and maintain a clean, readable, and structured version control history. Automation is a key aspect, with pre-commit hooks ensuring that all contributed code meets the established standards before it is integrated.

Tooling and Automation

The project's code quality workflow is managed by several key tools and scripts defined in the root package.json.

Script	Description
lint	Runs ESLint across all packages and apps using Turborepo.
lint:fix	Runs ESLint in --fix mode to automatically correct issues.
format	Formats all supported file types using Prettier.
format:check	Checks for formatting issues without writing changes.
prepare	Installs Husky for managing Git hooks.

Sources: package.json:7-13

Pre-commit Hooks

The project uses husky and lint-staged to automate code quality checks before each commit. When a developer runs git commit, husky triggers lint-staged, which in turn runs ESLint and Prettier on the files staged for the commit. This ensures that no code violating the project's style guide can be committed.

The following diagram illustrates the pre-commit workflow:

The lint-staged configuration is defined in package.json:

"lint-staged": {
  "*.{ts,tsx}": [
    "eslint --fix",
    "prettier --write"
  ],
  "*.{json,md,css,js}": [
    "prettier --write"
  ]
}

Sources: package.json:28-35

ESLint Configuration

The project utilizes a modular ESLint setup managed by the @repo/eslint-config shared package. This allows for different rule sets to be applied to different parts of the monorepo, such as the backend API versus the React-based frontend.

The root eslint.config.js orchestrates which configuration is applied to which workspace.

This diagram shows the ESLint configuration hierarchy:

Root Configuration (eslint.config.js)

The root configuration file imports the base and react configurations from the shared package. It then applies them selectively:

• react config: Applied to files ending in .ts and .tsx across the project, which primarily targets the web app and ui package.
• base config: Overrides the react config for specific non-React packages like apps/api and packages/types, ensuring only the base TypeScript rules apply there.

Sources: eslint.config.js:15-24

Shared Base Configuration (packages/eslint-config/base.js)

This is the foundation for all TypeScript projects in the monorepo. It is configured for a Node.js environment.

Key rules include:

Rule	Setting	Description
@typescript-eslint/no-explicit-any	error	Prohibits the use of the any type.
@typescript-eslint/no-unused-vars	error	Flags unused variables, ignoring those prefixed with _.
@typescript-eslint/consistent-type-imports	error	Enforces the use of import type for type-only imports.
no-console	warn	Allows console.warn and console.error but warns on other console usage.
eqeqeq	error	Requires the use of === and !==.
prefer-const	error	Requires const declarations for variables that are never reassigned.

Sources: packages/eslint-config/base.js:33-54

Shared React Configuration (packages/eslint-config/react.js)

This configuration extends the base settings and adds rules specific to React and JSX development. It is configured for a browser environment.

Key additions and rules include:

• Plugins: eslint-plugin-react, eslint-plugin-react-hooks.
• Settings: Automatically detects the React version.
• Rules:
  • react/react-in-jsx-scope: off (Not needed with modern React/Vite).
  • react-hooks/rules-of-hooks: error (Enforces the Rules of Hooks).
  • react-hooks/exhaustive-deps: warn (Warns about missing dependencies in useEffect and other hooks).
  • @typescript-eslint/consistent-type-imports: error (Enforces import type for consistency).

Sources: packages/eslint-config/react.js:43-90

Commit Message Linting

To maintain a clean and conventional Git history, the project uses commitlint with the @commitlint/config-conventional preset. This is enforced via a commit-msg Git hook managed by Husky.

The configuration in commitlint.config.js defines the structure and allowed types for commit messages.

Allowed Commit Types

Type	Description
feat	A new feature
fix	A bug fix
docs	Documentation only changes
style	Changes that do not affect the meaning of the code
refactor	A code change that neither fixes a bug nor adds a feature
perf	A code change that improves performance
test	Adding missing tests or correcting existing tests
build	Changes that affect the build system or external dependencies
ci	Changes to our CI configuration files and scripts
chore	Other changes that don't modify src or test files
revert	Reverts a previous commit

Sources: commitlint.config.js:6-18, commitlint.config.js:24-38

Commit Message Rules

In addition to the type, several other rules are enforced:

• The type must be one of the allowed values and in lower-case.
• The subject line cannot be empty.
• The subject line must not end with a period.
• The entire header (e.g., feat(scope): subject) must not exceed 100 characters.

Sources: commitlint.config.js:19-43

Summary

The project's linting and code style strategy is built on a robust, automated foundation. By combining ESLint, Prettier, and Commitlint within a Turborepo monorepo, it ensures that all code is consistent, readable, and free of common errors. The use of shared configurations promotes DRY principles, while pre-commit hooks guarantee that these standards are met before any code is integrated, leading to a more efficient development process and a higher quality codebase.