eslint-config-moneyforward development plan

[wakamsha]

We are developing a new version of eslint-config-moneyforward. Our aim is to significantly improve our previous development process and transition to a more comfortable and sophisticated one.

Below is an overview of the new development process. We'll update it if there are any changes:

About the Development Repository

We'll continue to develop in this repository, fully replacing the current design and releasing it as v3. However, we'll continue to maintain v2 for the time belong.

There was an idea to create a new repository separately from this one, but we decided it wasn't appropriate fro the following reasons:

• From the outside, it would appear as if there are two packages with exactly the same role. People who aren't familiar with the background information of both the existing and the new one wouldn't understand why there are multiple ones. Therefore, those considering adoption would be confused about whether to use the existing or the new one.
• If we keep everything in one repository, it's less confusing. New users will usually install the latest version. Current users just need to check the CHANGELOG to decide if they want to update, so they don't need to know about a new repository.

Code Owners

We will set up a new .github/CODEOWNERS.

We'll create a new GitHub Team for the purpose of maintaining this repository and add core contributors to it as Code Owners. By setting up a dedicated GitHub Team, we can configure members flexibly, independent of our company's organizational structure.

For the time being, we won't set individual account names as members. This is to avoid the need to update the file every time someone leaves the team due to a transfer or resignation (the same applies when a new member joins).

References

• コードオーナーについて - GitHub Docs
• GitHub で Code Owners を会社として活用する

Pull Request Template

We'll create a new template.

Code Review

Language

All pull request explanations and review comments will be in English.

Review Policy

We'll accept and merge Pull Requests from external contributers when all of the following requirements are met:

• The Pull Request complies with the policies and roadmap set by this project.
• The objectivity and rationality of the Pull Request are clearly presented.
• All CI/CD checks have passed.

However, if the reviewer determines that the objectivity or rationality of the Pull Request itself is insufficient, they may request additional explanation.

If minor differences in code formatting or coding style are observed, we'll carry out refactoring within the team after the merge.

Conditions for merging

• All CI/CD checks have passed.
• There is at least one approval from Code Owners.

CI Design

Updating Dependent Packages

We'll transition from Dependabot to Renovate. Renovate can be considered a superior alternative to Dependabot.

We'll use Renovate to design and automate the continuous updating of dependent packages. Renovate is a tool specialized in automatically creating Pull Requests to update dependent packages, and its behavior can be very finely controlled, so it can be introduced in a way that suits the circumstances of the development team.

On the other hand, GitHub is equipped with a tool called Dependabot, which automatically detects packages with security risks and creates Pull Requests to update their versions. However, Dependabot is primarily intended for quick notification of security patches, and doesn't necessarily align with the goal of continues updating of dependent packages. Therefore, even if it's introduced, it may not lead to problem solving, and the wave of endlessly generated Pull Requests can easily be overwhelming and neglected. The main focus should be on the continuous updating of dependent packages, and it's necessary to establish a solution to achieve this at a low cost.

Pull Requests automatically generated by Dependabot detecting vulnerabilities in dependent packages are treated the same as Pull Requests from external contributors, and core contributors will handle them.

Renovate Settings

• The extension of the configuration file shold be .json.
• Base on config:js-lib.
• minor and patch updates will be automatically merged if they pass the CI/CD.
• No settings for automatic assignment of reviewers.
  • Automatic assignment by .github/CODEOWNERS settings takes precedence, so it won't work in the first place.
• The schedule is set to "the 1st of every month". ESLint-related packages have a relatively slow update cycle, so we'll start by observing the situation on a monthly basis.

  {
    "schedule": ["before 4am on the first day of the month"]
  }

Unit Test

Since Jest has already been introduced, we'll continue to use it to expand out unit tests.

Test perspective

• Check whether the entry point file exist as expected.
• Check whether the various setting values are as expected.

References

• ESLint の設定を ESLint でテストする. 今回は ESLint の設定を ESLint… | by Shingo Sasaki | スタディスト Tech Blog
• ESLintの設定値が期待した値になっているか確認するテストマッチャーを作ろう - Chatwork Creator's Note
• https://github.com/RobinCsl/how-to-test-your-eslint-config

CD Design

Release Workflow

The release of OSS packages generally encompasses the following processes:

• Determining the next version number.
• Publishing to npm.
• Creating a Release Node or CHANGELOG.

There are many tools to automate these processes, and we'll select the appropriate one. In this project, we'll adopt semantic-release. It has the following features:

• It comprehensively automates the release workflow, including determining the next version number (compliant with emVer2), generating release notes, and publishing packages.
• It refers to commit messages to judge how changes in the codebase will affect users and selects the next version number. Therefore, commit messages are required to be in a format that complies with Conventional Commits.
• Two release methods are available:
  • Full automation by CI:
    The entire release workflow is executed as CI every time a build is successful on the release branch. You can also run a workflow at any time by using GitHub Action's workflow_dispatch as trigger.
  • A method triggered by pushing to any branch:
    Upon receiving a push to any base branch (such as main, next, beta etc...), if it's judged that the difference will affect the functionality of the previous release workflow is executed.
• It can be used in monorepo by introducing semantic-release-monorepo.
• Used by Airbnb.

The following are the reasons for adopting semantic-release.

• The automatic selection of the next version number is the most distinguishing feature, and its algorithm is also rational, inferred from Conventional Commit.
  • A certain order is positively enforced in the commit message at the time of Squash merge (i.e., the Pull Request title).
• Although monorepo isn't supported as default, it can be supported by introducing a plugin.
  • There are no plans to convert to monorepo at the moment.
• The existing tool, release-it, is simple because it focuses on manual control, but this means that additional design costs are required to ensure consistency.

References

• CHANGELOG生成系について調べてみた - くらげになりたい。
• Squash and merge で Conventional Commits の規約に則ったコミットメッセージにする
• リリース自動化の嬉しみとその手法 - Kengo's blog

Branch Strategy

Trunk-Based Development

We define the main branch as the trunk and carry out all development work here as a principle.

Trunk-based development is a development method where all developers work on a single main branch, break down the work needed for feature development into smaller tasks, and commit to the main branch frequently in a short period of time (commits are made via Pull Requests, not directly).

References

• DORA | DevOps Capabilities: Trunk-based Development

Node

If it becomes necessary to apply a patch to v2 after the v3 release, a separate trunk for v2 will be created and released from there.

Merge Strategy

We use "Squash merge".

References

• Merge strategies and squash merge - Azure Repos | Microsoft Learn

Hotfix

We don't operate a Hotfix branch.

Pull Request Title

In this project, we adopt semantic-release to automate the release flow.

semantic-release determines the version number of the next release from commit messages, generates a changelog, and performs the release process. By default, it makes judgements from a format called Angular Commit Message Conventions. Therefore , developers are required to have commit messages in the appropriate format, and tools like commitizen or commitlint are usually introduced. However, since the merge strategy of this project is "Squash merge", a consistent format is required for the commit message when merging into the trunk (individual commit messages during development aren't inspected). The commit message when merging into the trunk with "Squash merge" is first suggested by the title of that Pull Request, so a support tool is needed to unify this into an appropriate format.

Reference: README - semantic-release

Checking the Format of Pull Request Titles with GitHub Action

We'll introduce amannn/action-semantic-pull-request.

This GitHub Action's README explicitly mentions its use with semantic-release.

In addition, when using "Squash and merge" for a Pull Request with only one commit, GitHub suggests the message of that single commit, not the PR title, but this GHA checks that as well. Specifically, it checks whether the message of that single commit is the same as the Pull Request title. If the two strings are different or do not comply with the conventional commit format, it will result in an error.

The default types only recognize fix and feat, so we will add the following defined in the Angular convention.

• build
• chore
• ci
• docs
• style
• refactor
• perf
• test

References:
https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines