Code Formatting with Prettier and ESLint

To ensure consistency and readability across our codebase, we use two primary tools for formatting and linting our code: Prettier and ESLint.

Prettier

Prettier is an opinionated code formatter that supports many languages and integrates with most editors. The core idea behind Prettier is to remove all original styling and ensure that all outputted code conforms to a consistent style. This eliminates the ongoing discussions about styles in code review and saves you time and energy.

Key Features:

• Consistency: Automates formatting code to look the same regardless of who wrote it.
• Support: Works with many languages and frameworks, integrates into most editors.
• Customizability: While opinionated, Prettier allows configuration of certain style preferences via a .prettierrc file.

ESLint

ESLint is a highly configurable tool for identifying and reporting on patterns in JavaScript, with the goal of making code more consistent and avoiding bugs. It is widely used for enforcing a coding standard, finding problematic patterns, or code that doesn’t adhere to certain style guidelines. Key Features:

• Custom Rules: ESLint rules can be configured in several ways and it supports a wide range of plugins to support various JavaScript tools and libraries.
• Fix Automatically: ESLint can automatically fix many of the issues it detects, making it easier to maintain a clean codebase.
• Plugin System: Allows the use of third-party plugins. By default, we use the recommended plugin sets for TypeScript, which include best practices and common conventions.

Integration of Prettier and ESLint

To avoid conflicts between Prettier and ESLint, we utilize the eslint-plugin-prettier which runs Prettier as an ESLint rule and reports differences as individual ESLint issues. This integration ensures that our formatting choices made by Prettier align with the linting policies set by ESLint, providing a seamless and conflict-free development experience.

We configure ESLint with the recommended settings for TypeScript, supplemented by a few of our own custom rules. This combination allows us to leverage the strengths of both tools:

1. ESLint for Code Quality: Focuses on code-quality issues, ensuring that our code is not only consistent but also free of potential errors.
2. Prettier for Style Enforcement: Ensures that the style aspects of our code are uniformly applied, saving developer time and reducing code review overhead.

Our Custom ESLint Rules

Here, I’ll describe some of the custom rules we’ve added to our ESLint setup:

event-dispatcher-owner-check

Pretty self explanatory, this rule enforces that the second parameter of the EventManager is always an object.

consistent-type-imports:

Makes sure that things are imported as type imports whenever possible. These imports are dropped at compile time which helps with tree-shakability and avoiding circular dependencies.

no-useless-path-segments

Prevents imports ending with "/". If a class is imported in two places, one ending in "/" and one not, javascript creates two instances of the class, which is wasteful and can lead to other problems.

no-relative-packages

Prevents importing things from other packages using relative paths. This is combined with "no-restricted-imports" to prevent packages from importing things in a way that violates the project hierarchy.

Using these tools together enhances our productivity and ensures that both new and existing code adheres to our organizational standards. This dual-tool setup helps maintain a high level of code quality throughout our projects, fostering a codebase that is both clean and efficient.

Small Configuration Note

If you are using an IDE that has its own ESLint and Prettier plugins, make sure to set them to avoid conflicts with the project configuration (by picking the projects prettier and eslint). This will ensure that the project-specific settings are applied consistently across all developers and environments, as prettier behaves differently depending on the version.