SalesforceのISVならともかく、組織でSalesforceを使う人たちで複数パッケージで開発しているところは、調べた限り少ないです。
組織でロック解除済みパッケージを使うとして、複数プロジェクト分割時にどういう開発プロセスになるのか知りたくて、検証してみます。
準備
自分で複数プロジェクトのソースを用意するのが大変だったので、サンプルを持ってきました。
とっても助かります。
また、Salesforce組織はTrailhead Playgroundを使います。「Dev Hubを有効化」と「ロック解除済みパッケージと第二世代管理パッケージを有効化」をどちらも有効にします。その他クライアント環境は以下の通りです。
| 環境 | バージョンなど |
|---|---|
| OS | Windows10 |
| Editor | Visual Studio Code |
| SFDX | sfdx-cli/7.63.0-c897e8bb1a |
| shell | Powershell7.0.1*1 |
手順
既に、SFDXでTrailhead Playgroundには接続しているものとします。
組織起動、ソース等のpush
sfdx force:org:create -f .\config\project-scratch-def.json -a easylwc sfdx force:org:open -u easylwc
スクラッチ組織を起動するところまでは上記です。
sfdx force:source:push -u easylwc
組織へのpushです。結構時間かかるので待ちましょう。権限付与などは、GitHubリポジトリの説明にあるので、そちらを参照ください。
これで、開発環境が整います。開発中はパッケージに固めたものを使いません。（たぶん）
変更を加える
新規オブジェクトを足してみます。Salesforce組織上で行います。
変更を確認します。
sfdx force:source:status -u easylwc === Source Status STATE FULL NAME TYPE PROJECT PATH ────────── ───────────────────────── ──────────── ──────────── Remote Add Admin Profile Remote Add Custom: Sales Profile Profile Remote Add Custom: Marketing Profile Profile Remote Add Custom: Support Profile Profile Remote Add House__c-Houseレイアウト Layout Remote Add House__c CustomObject
pullする
sfdx force:source:pull -u easylwc === Pulled Source STATE FULL NAME TYPE PROJECT PATH ───── ─────────────────── ──────────── ────────────────────────────────────────────────────────────────────── Add House__c CustomObject es-space-mgmt\main\default\objects\House__c\House__c.object-meta.xml Add House__c-Houseレイアウト Layout es-space-mgmt\main\default\layouts\House__c-Houseレイアウト.layout-meta.xml
ふむ。es-space-mgmtディレクトリに入ってきたようです。
なぜこのディレクトリなのか
おそらくですが、sfdx-project.jsonの定義上、es-space-mgmtがデフォルトパッケージとなっているから、です。
// 略 { "path": "./es-space-mgmt", "package": "ESSpaceMgmtLWC", "versionName": "Space Management App - Spring '20", "versionNumber": "4.0.0.NEXT", "default": true, // 略 }
もし、特定のパッケージにこのソースを含めたい（今回ならes-base-objectsパッケージに入れる）場合は、ローカルでソースを移動させた後に、パッケージを作成して動作確認、という手順を踏むのでしょう。
つまり、開発中はある程度の整理ができていれば十分そうです。
なお、既存のメタデータに対する変更は、元のパッケージディレクトリに反映されます。
例：Market__cにカスタムフィールド追加（権限セットも変更）
statusはこうなります。
sfdx force:source:status -u easylwc === Source Status STATE FULL NAME TYPE PROJECT PATH ────────────── ───────────────── ───────────── ──────────────────────────────────────────────────────────────────────────────────── Remote Add Market__c.Memo__c CustomField Remote Changed EasySpacesObjects PermissionSet es-base-objects\main\default\permissionsets\EasySpacesObjects.permissionset-meta.xml
pullします。
=== Pulled Source sfdx force:source:pull -u easylwc === Pulled Source STATE FULL NAME TYPE PROJECT PATH ─────── ───────────────── ───────────── ──────────────────────────────────────────────────────────────────────────────────── Add Market__c.Memo__c CustomField es-base-objects\main\default\objects\Market__c\fields\Memo__c.field-meta.xml Changed EasySpacesObjects PermissionSet es-base-objects\main\default\permissionsets\EasySpacesObjects.permissionset-meta.xml
ちゃんと、元あったオブジェクト部分に変更が反映されています。
軽いまとめ
sfdx force:source:pushは、パッケージとして定義されていたら組織にpushされる
sfdx force:source:pullは、組織の変更をデフォルトパッケージに取り込む。必要ならそこから移動させる
パッケージ分割は、あくまでリリース時に考慮することで、開発中はそこまで考えなくてもいい。（ただし双方向参照とかを作ってしまった場合はそれらを同一パッケージに含める必要があるなど、設計段階で考慮する事項はある）
おわりに
今回の記事、ほとんど自分用のメモです。SFDXのpushやpullがどういう挙動か知らないと、いざというときに困りそうなので調査しています。特に複数パッケージを扱う時のドキュメントが見当たらず状態だったので、手探りでやっています。
また何か試したら記事にします。
