CI Checks: Implement Best Practices For Code Quality

by Sebastian Müller 53 views

Alright, guys, let's dive into implementing some crucial CI checks for our repos! We need to make sure we're following common patterns to keep everything consistent and smooth. This will involve upgrading dependencies, configuring linters and formatters, setting up testing, and automating dependency updates. So, let's get our hands dirty and make our development process rock solid!

Acceptance Criteria

Here's the breakdown of what we need to accomplish:

  • [ ] Upgrade or install the latest versions of ESlint, Prettier, and Vitest dependencies.
  • [ ] Since there are several packages in this repo, explore ways to re-use ESlint, Prettier, and Vitest configs.
  • [ ] Add a Vitest config with a simple example test.
  • [ ] Dependabot is implemented as close as possible to this PR.
    • [ ] You may need to add package-lock.json to .prettierignore to avoid issues.
  • [ ] ESLint should be configured as close as possible to this PR:
    • [ ] Same rule set in general.
    • [ ] All recommended Sonarcloud rules enabled.
    • [ ] Skip JS rules config from the linked sample as this repo is TS-only.
    • [ ] Add some recommended React-specific rules.
  • [ ] If there are many linter issues that cannot be auto-fixed, create a follow-up task to fix these.
  • [ ] Add CI checks with GitHub Actions that should be configured as close as possible to this PR.
    • [ ] Build checks should be based on npm pack if possible.
  • [ ] .prettierrc should be exactly as in this PR. Re-format the codebase if necessary:
{
  "tabWidth": 2,
  "singleQuote": true,
  "printWidth": 120
}

Diving Deep into CI Implementation

Upgrading and Installing Dependencies

First off, let's talk about keeping our tools sharp! We're going to start by upgrading or installing the latest versions of ESLint, Prettier, and Vitest. Why is this important, guys? Well, newer versions often come with bug fixes, performance improvements, and shiny new features that can make our lives as developers much easier. Plus, staying up-to-date ensures compatibility and helps us avoid potential security vulnerabilities. Think of it as giving our development environment a regular health checkup. We want everything running smoothly, right? To get this done, we’ll be using npm or yarn, depending on the project's package manager. A simple npm install eslint prettier vitest --save-dev or the equivalent yarn add eslint prettier vitest --dev command will do the trick. After that, we can move on to the more interesting stuff – configuring these tools to work together seamlessly.

Reusing ESLint, Prettier, and Vitest Configurations

Now, let’s chat about efficiency. Since this repo has multiple packages, we don't want to repeat ourselves, do we? That's where reusability comes in. We need to explore ways to reuse our ESLint, Prettier, and Vitest configs. Imagine having to update the same rule in multiple places – that's a recipe for headaches and inconsistencies. The goal here is to create a single source of truth for our configurations. One common approach is to create a root-level configuration file (like .eslintrc.js, .prettierrc.json, and vitest.config.js) and then have each package extend or import from this central config. This way, if we need to make a change, we only need to do it in one place. Think of it like having a master template that all our packages follow. This not only saves us time and effort but also ensures that our code style and testing standards are consistent across the entire project. It’s all about working smarter, not harder, right?

Adding a Vitest Configuration with a Simple Example Test

Testing, testing, 1, 2, 3! Let's make sure our code works as expected by adding a Vitest config with a simple example test. Testing is super crucial, guys. It helps us catch bugs early, ensures our code behaves correctly, and gives us the confidence to make changes without breaking everything. Vitest is a fantastic testing framework that's fast and easy to use, especially if you're already familiar with Jest. To get started, we'll create a vitest.config.js file in the root of our project. This file will contain our test configuration, such as the test environment, reporters, and any other settings we need. Then, we'll create a simple test file (e.g., test/example.test.ts) with a basic test case. This could be as simple as asserting that 1 + 1 equals 2. The key here is to get the testing framework up and running and to have a basic test in place. This gives us a foundation to build upon as we add more complex tests in the future. Think of this as the first step in building a robust safety net for our code. We want to catch those pesky bugs before they cause trouble!

Implementing Dependabot for Automated Dependency Updates

Keeping our dependencies up-to-date can be a real drag, but it’s a necessary evil. That's where Dependabot comes in to save the day! We aim to implement Dependabot as closely as possible to the configuration in this pull request. Dependabot is a fantastic tool that automatically checks our dependencies for updates and creates pull requests to update them. This helps us stay on top of security vulnerabilities and bug fixes without having to manually check for updates ourselves. To set up Dependabot, we'll need to create a .github/dependabot.yml file in our repository. This file will contain the configuration for Dependabot, such as which package managers to check and how often to check for updates. We'll be closely following the configuration from the linked pull request to ensure we have a solid setup. One thing to watch out for is potential conflicts with Prettier. Sometimes, Dependabot's changes can cause formatting issues. To avoid this, we might need to add package-lock.json to our .prettierignore file. It's all about automating the boring stuff so we can focus on the fun stuff – writing code!

Configuring ESLint for Code Quality

Let's talk about code quality, guys! We want to make sure our code is clean, consistent, and easy to read. That's where ESLint comes in. We need to configure ESLint as closely as possible to the setup in this pull request. This means using the same rule set in general, enabling all recommended Sonarcloud rules, skipping the JS rules config (since this repo is TS-only), and adding some recommended React-specific rules. ESLint is a powerful linter that helps us identify and fix code style issues, potential bugs, and other problems. By following a consistent set of rules, we can ensure that our codebase is maintainable and readable. To configure ESLint, we'll create an .eslintrc.js file in the root of our project. This file will contain our ESLint configuration, including the rules we want to enforce, any plugins we want to use, and any other settings. We'll be closely following the configuration from the linked pull request to ensure we have a robust setup. This includes enabling all recommended Sonarcloud rules, which will help us catch potential code smells and security vulnerabilities. Since this repo is TypeScript-only, we can skip the JS rules config from the linked sample. We'll also add some recommended React-specific rules to ensure our React code is up to snuff. It’s like having a code quality watchdog that keeps our codebase in tip-top shape!

Addressing Linter Issues and Follow-Up Tasks

Okay, so what happens if ESLint finds a bunch of issues that can't be automatically fixed? Don't panic! If we find many linter issues that cannot be auto-fixed, we'll create a follow-up task to fix these. We don't want to get bogged down in fixing every single issue right away, especially if there are a lot of them. The goal here is to get the CI checks in place and then tackle the remaining issues in a separate task. This allows us to make progress without getting overwhelmed. We'll create a new issue or task in our project management system (e.g., Jira, Trello) and list out all the remaining ESLint issues. Then, we can prioritize them and work through them systematically. This approach helps us keep our codebase clean and consistent without blocking our progress on other tasks. It's all about breaking down big problems into smaller, manageable chunks. Rome wasn't built in a day, and neither is a perfect codebase!

Adding CI Checks with GitHub Actions

Now, let's automate the whole process! We need to add CI checks with GitHub Actions that should be configured as closely as possible to this pull request. CI, or Continuous Integration, is a practice where we automatically build and test our code whenever we make changes. This helps us catch issues early and often, before they make their way into production. GitHub Actions is a fantastic tool that allows us to automate our CI/CD workflows directly within GitHub. To set up CI checks, we'll create a .github/workflows directory in our repository and add a YAML file (e.g., ci.yml) that defines our workflow. This file will specify the steps that should be run whenever we push code or create a pull request. These steps might include installing dependencies, running linters, running tests, and building our application. We'll be closely following the configuration from the linked pull request to ensure we have a solid CI setup. This includes basing our build checks on npm pack if possible, which will help us ensure that our published package is correct. Think of CI as our automated quality assurance team. It's always on the lookout for problems, so we can focus on writing great code!

Configuring Prettier for Code Formatting

Last but not least, let's talk about code formatting. We want our code to look consistent and beautiful, right? That's where Prettier comes in. Our .prettierrc file should be exactly as in this pull request. This means using a tabWidth of 2, singleQuote set to true, and a printWidth of 120. Prettier is an opinionated code formatter that automatically formats our code according to a set of rules. This helps us maintain a consistent code style across our entire project, without having to manually format everything ourselves. To configure Prettier, we'll create a .prettierrc.json file in the root of our project and add the configuration from the linked pull request. If necessary, we'll re-format the codebase to ensure it adheres to these rules. This might involve running a command like npx prettier --write . to automatically format all the files in our project. Think of Prettier as our personal code stylist. It makes our code look good, so we don't have to worry about the small stuff!

By following these steps, we'll have a robust CI pipeline in place that helps us maintain code quality, catch bugs early, and automate our development process. Let's get to it, guys!