eslint-plugin-no-barrel-filesを導入してBarrel filesをやめた話

2025年1月28日

URLをコピーしました！

こんにちは、フロントエンドエンジニアのやなぎ（@apple_yagi）です。

PR TIMESではフロントエンドのReactリプレイス当初より Barrel file を作成するルールがありました。しかし、先日そのルールを廃止することに決めたため、その経緯についてご紹介します。

Barrel filesとは

Barrel filesとは複数のモジュールを1つのファイル（Barrel file）にまとめてexportすることを指します。以下の例ではutils/test.ts 、utils/fuga.ts 、utils/hoge.ts で export されている定数を utils/index.ts で再exportしています。

// utils/test.ts
export const test = 1;

// utils/fuga.ts
export const fuga = 2;

// utils/hoge.ts
export const hoge = 3;

// utils/index.ts
export * from './test';
export * from './fuga';
export * from './hoge';

これによって、utils/test.ts、utils/fuga.ts、utils/hoge.tsの各ファイルを使用する際に、import文をスッキリ書くことが可能です。

import {test, fuga, hoge} from './utils';

// Barrel fileを使用しない場合
import {test} from './utils/test';
import {fuga} from './utils/fuga';
import {hoge} from './utils/hoge';

Barrel files をやめた経緯

前述した通り、PR TIMESではReactリプレイス当初から Barrel file の作成をルールとしていました。しかし、それから数年が経過した現在、そのルールはあまり浸透しておらず、メンバー間で実施の有無が分かれていました。これは、明文化されたコーディングルールがなく、Pull Requestのレビューでの指摘に依存していたためです。

Reactリプレイスを始めた当時はフロントエンドメンバーがわずか3人でしたが、今ではバックエンドエンジニアもフロントエンド開発に参加するようになり、チームは10人を超える規模になりました。そのため、レビューを通じてのみルールを徹底させるのは現実的ではなくなっています。

さらに、昨年lintツールをXOに統一した際、Barrel filesが原因でimport/no-cycleのlintエラーが多発していました。一時的にはinlineでルールを無効にして対処していましたが、Barrel filesが循環参照のリスクを引き起こすことが明らかになりました。以下の記事にもこのことについて言及されています。

また、最近ではBarrel filesのデメリットについて言及する記事が増え、Next.jsやJest、Vitestなどのテストランナーでパフォーマンスの劣化が生じるとの報告もありました。現在のPR TIMESではBarrel fileの数は多くないため、パフォーマンスに影響は感じていませんが、将来的に顕著になる可能性があります。

これらの理由を踏まえ、Barrel filesの使用をやめ、eslint-plugin-no-barrel-filesを導入することにしました。

eslint-plugin-no-barrel-filesの選定理由

Barrel filesを禁止するlintルールを提供しているeslint pluginはeslint-plugin-no-barrel-files以外にも以下のようにいくつか存在します。

1つ目の eslint-plugin-barrel-files はflat config化対応がまだされていなかったため、使用しませんでした。

2つ目の eslint-plugin-canonical については、今回のように Barrel files の使用を制限したいという目的に対して付属しているルールが多く、fatだと判断したため使用しませんでした。しかし、今後 eslint-plugin-canonical にある他のルールを適用したいと思ったタイミングで移行する可能性がありそうです。

まとめ

今回、レビューでのみ運用していたBarrel filesのルールを見直し、廃止することにしました。また、機械的にルールを運用できるようにeslint pluginを追加し、レビューでの指摘のみに頼らないルール運用を開始しました。

PR TIMESのフロントエンドのコーディングルールはドキュメントを作って運用とはしておらず、ESLintを正としてコーディングルールを運用しています。今回のBarrel filesのルールはESLintで運用されていなかったため、曖昧な状態で運用されていました。この教訓を生かして、今回のような曖昧なルールを見つけた際はESLintによって管理していきたいと思います。