Skip to content

Code Quality ​

This guide details the standards and tools used to maintain high code quality and consistency in the Bagisto Headless storefront.

Overview ​

We follow industry-standard practices to ensure the codebase remains clean, readable, and free of common errors. This is achieved through automated linting, strict type checking, and standardized formatting.

1. ESLint Configuration ​

The project uses ESLint 9 with the Flat Config system (eslint.config.mjs) to enforce coding standards.

Core Plugins ​

  • Next.js Vitals: Ensures the code follows Next.js performance and accessibility best practices.
  • TypeScript ESLint: Provides specialized rules for TypeScript codebases.

Configured Rules ​

Our configuration focuses on catchable errors and code cleanliness:

  • @typescript-eslint/no-unused-vars: Errors on unused variables (allows patterns starting with _).
  • no-console: Warns against using console.log in production code (allows warn and error).
  • @typescript-eslint/no-explicit-any: Warns when the any type is used, encouraging specific type definitions.
  • react-hooks/exhaustive-deps: Ensures all dependencies are included in React hooks like useEffect.

Run Linting:

bash
npm run lint

2. TypeScript Strict Mode ​

The project is built with TypeScript in Strict Mode to catch potential bugs at compile-time.

File: tsconfig.json

json
{
  "compilerOptions": {
    "strict": true,
    "skipLibCheck": true,
    "noEmit": true
  }
}

Key Strict Features: ​

  • strictNullChecks: Prevents "null is not an object" errors by forcing explicit handling of potentially null/undefined values.
  • noImplicitAny: Ensures every variable has a known type, preventing accidental use of any.
  • strictFunctionTypes: Ensures function parameters and return types are compatible.

3. Formatting Standards ​

While ESLint handles many stylistic choices, the project follows a consistent formatting pattern:

  • Indentation: 2 spaces.
  • Quotes: Double quotes for strings.
  • Semicolons: Always used.
  • Imports: Organized by path aliases (@/, @components/, etc.).

Recommendation: Use the Prettier extension in your IDE for real-time formatting alignment.

4. Code Reviews ​

To maintain quality, every pull request should be reviewed for:

  • Logic Correctness: Does it solve the user's problem without side effects?
  • Performance: Are there unnecessary re-renders or heavy computations?
  • Type Safety: Are types specific and well-defined?
  • Readability: Is the code self-documenting, or are comments needed for complex logic?

Next Steps ​

Released under the MIT License.