クラウド同期フォルダでアプリ開発するとビルドが壊れる — 生成物を同期から外して根治した話

Dropbox：拡張属性で個別に除外する

Dropbox には、フォルダごとに「同期しない」と指定できる拡張属性があります。macOS なら xattr コマンドで、対象フォルダに com.dropbox.ignored を立てます。手順は次の通りです。

1. 既存の競合コピーを削除して状態を綺麗にする
2. 対象フォルダに com.dropbox.ignored の属性を立てる
3. 属性が立っているかを xattr -p で確認する

# 対象フォルダを Dropbox の同期対象から外す（macOS）
# 値に 1 を立てると、そのフォルダはローカルに残るが同期されない
xattr -w com.dropbox.ignored 1 ios/Pods
xattr -w com.dropbox.ignored 1 node_modules
 
# 立っているか確認する（1 が返れば除外済み）
xattr -p com.dropbox.ignored node_modules
# => 1

注意点として、除外してもフォルダはローカルに残ります。ビルドはこれまで通り動き、ただクラウドには上がらなくなります。既に競合コピーが散らばっている場合は、先にそれらを削除してから属性を立てると綺麗になります。

# 既存の競合コピーを一掃してから除外属性を立てる
find . -name "*競合コピー*" -o -name "*conflicted copy*" | while read f; do
  echo "removing: $f"
  rm -rf "$f"
done

iCloud Drive：命名規約と退避で外す

iCloud Drive には Dropbox のような専用属性がありません。代わりに2つの現実的な対処があります。

ひとつは、末尾が .nosync のファイル／フォルダは iCloud が同期しないという規約を使う方法。ただしフォルダ名を変えるとビルドツールが参照先を見失うため、生成物ディレクトリそのものには使いにくい。

もうひとつが確実です。プロジェクトの作業ディレクトリを iCloud の外に置く。 ソースは ~/Developer/ のような同期対象外の場所に置き、成果物だけを必要に応じて iCloud にコピーする運用にします。私はこの場合、リポジトリを丸ごと ~/Developer/ に clone し直す方を選びます。生成物を「外そう」とするより、生成物を「最初から同期領域に作らない」方が事故が少ないからです。

再発を止める：プロジェクト作成時に流す1本のスクリプト

一度手で除外しても、新しいプロジェクトを作るたびに忘れます。私は新規セットアップの最後に必ず流す小さなスクリプトを1本用意し、生成物を機械的に除外するようにしました。

#!/usr/bin/env bash
# dropbox-ignore-build-artifacts.sh
# プロジェクトルートで実行し、再生成可能なディレクトリを Dropbox 同期から外す。
set -euo pipefail
 
# 除外対象（再生成できるものだけを列挙する）
TARGETS=(
  "node_modules"
  "ios/Pods"
  "ios/build"
  "android/build"
  "android/.gradle"
  ".gradle"
  ".expo"
  ".expo-shared"
)
 
for dir in "${TARGETS[@]}"; do
  if [ -d "$dir" ]; then
    xattr -w com.dropbox.ignored 1 "$dir"
    echo "ignored: $dir"
  else
    # まだ生成されていないものは、空ディレクトリを作って先回りで属性を立てる
    mkdir -p "$dir"
    xattr -w com.dropbox.ignored 1 "$dir"
    echo "pre-created & ignored: $dir"
  fi
done
 
echo "done. 除外済みフォルダはローカルに残りますが同期されません。"

先回りで空ディレクトリを作って属性を立てているのが小さな工夫です。node_modules がまだ無い状態で属性だけ立てておけば、その後の npm install が展開する中身は最初から同期対象外になります。生成物が生まれる前に除外を確定させるのが、競合コピーを1つも作らせない解決策でした。

効いているかを確かめる

属性を立てたら、少し放置して観察します。私は3日ほど普段通りに開発とビルドを回し、競合コピーが1つも増えないことを確認しました。

# 競合コピーが増えていないか定期的に数える
find . \( -name "*競合コピー*" -o -name "*conflicted copy*" \) | wc -l
# => 0 が続けば成功

数字が 0 のまま張り付けば、同期とビルドの綱引きは終わっています。ダッシュボードのような派手な成果ではありませんが、朝いちばんにビルドが赤い、という一番やる気を削がれる事故が消えました。

まとめ

まずは今開いているプロジェクトで node_modules に競合コピーが混ざっていないか、find . -name "*競合コピー*" を一度流してみてください。1つでも見つかったら、それが不定期なビルド失敗の温床です。

個人開発では開発環境を自分で整える手間が全部自分に返ってきます。私自身、原因が掴めないまま「クリーンして再ビルド」を何度も繰り返していました。生成物を同期から外すという一手は地味ですが、一度決めれば静かに効き続けます。お読みいただきありがとうございました。