every Tech Blog

株式会社エブリーのTech Blogです。

Jetpack Compose のbeta版を触ってみた

f:id:nanakookada:20210318191929p:plain

はじめに

日本時間の2021年2月25日に Jetpack Compose のbeta版がリリースされました。APIも固まってきたようですので触ってみた範囲のうち、導入的なところをコードで示しつつ、感想を述べていきます。

使用環境

使用した環境は以下の通りです。他にもandroidx.activityなどにcomposeがありますが、いずれも2021年3月15日時点で最新のバージョンを使用しました。
バージョンはJetpackのLibraries(*1)から調べることができます。

  • Android Studio Arctic Fox | 2020.3.1 Canary 9
  • androidx.compose 1.0.0-beta02

最初につくるもの

トップレベルの関数に @Composable を指定することで、その関数内にてComposeを使用したレイアウトを組めます。合わせて @Preview を指定すればAndroid Studio上でプレビューもできます。
このプレビューは同時に複数表示可能なので、プレビュー用の関数を複数作成すればダークテーマ対応有り/無しの表示を同時に確認できます。

@Composable
fun MyScreen() {
    // ここでComposeを使用して表示を組む
}

@Preview
@Composable
fun PreviewMyScreen() {
    // MyScreenで組んだ表示がAndroid Studio上にプレビューされる
    MyScreen()
}

レイアウトたち

Box、Column、Rowがそれぞれ従来のFrameLayoutやinearLayoutに相当しています。

Box {
    // 重なる
    Text("hoge")
    Text("piyo")
}

Column {
    // 縦に並ぶ
    Text("hoge")
    Text("piyo")
}

Row {
    // 横に並ぶ
    Text("hoge")
    Text("piyo")
}

他に、gradleファイルに指定を追加することでCompose版のConstraintLayoutも使えますが、公式Document中のConstraintLayoutの補足(*2)を読むと無理して使わなくても良さそうです。

// テキスト2つを縦に並べる
ConstraintLayout {
    val (text1, text2) = createRefs()

    Text(
        "hoge",
        modifier = Modifier.constrainAs(text1) {
            linkTo(
                parent.start, parent.top, parent.end, text2.top,
                0.dp, 0.dp, 0.dp, 8.dp
            )
        }
    )
    Text(
        "piyo",
        modifier = Modifier.constrainAs(text2) {
            linkTo(
                parent.start, text1.bottom, parent.end, parent.bottom,
                0.dp, 0.dp, 0.dp, 0.dp
            )
        }
    )
}

表示のパーツたち

Text、Button、Image、Cardなど多くの表示が揃っています。Spacerなるものもあり、わかりやすくmarginを仕込めます。
ただ、RecyclerView(ListView)相当がLazyColumn(or LazyRow)という名称であったりと、一部は従来の名前から大きく変わっている点に注意が必要です。

val items = (0 until 100).map { "item $it" }

LazyColumn(
    // 項目の間隔を空ける
    verticalArrangement = Arrangement.spacedBy(8.dp)
) {
    item {
        // リストの一番上に横スクロールのリストを入れる
        LazyRow(
            horizontalArrangement = Arrangement.spacedBy(8.dp)
        ) {
            items(items) { Text(it) }
        }
    }

    items(items) {
        // 縦スクロールのリストの項目としてテキストとボタンを横に並べる
        Row {
            Text(it)
            Spacer(modifier = Modifier.width(8.dp))
            Button(onClick = {
                // ボタンクリック時の処理
            }) {
                Text("button")
            }
        }
    }
}

ものが多すぎるので使いたいものを公式Reference(*3)から頑張って探す必要があります。androidx.composeパッケージ関連を漁れば色々と見つかります。

表示の設定を変更する

これまでレイアウトのxmlで指定していたlayout_widthやpaddingなどは Modifier というobjectを通して設定します。 Modifierにサイズやpaddingを設定する拡張関数があり、ものによってはColumnなどのscope限定で使える拡張関数が存在していることもあります。

Box(
    // 縦横とも画面一杯に広げてpaddingを設ける
    modifier = Modifier
        .fillMaxSize()
        .padding(16.dp)
) {
    Text(
        "hoge",
        // 背景を赤色かつ角に丸みを与え、中央に配置する
        modifier = Modifier
            .background(Color.Red, shape = RoundedCornerShape(8.dp))
            .align(Alignment.Center)
    )
}

表示の操作として行えることはModifierの関数だけなのでわかりやすいです。

ガワを作る

Scaffold() でMaterial Designに則った画面を簡単に構築できます。各種AppBarやFABを設定できる口があるので、従って作るだけでそれらしい画面になります。

Scaffold(
    // 他にもbottomBarやfloatingActionButtonなどを設定できる口がある
    topBar = {
        TopAppBar(
            title = { Text("title") },
            actions = {
                IconButton(onClick = {
                    // メニュークリック時の処理
                }) {
                    Icon(
                        imageVector = Icons.Default.ImageSearch,
                        contentDescription = "search"
                    )
                }
            }
        )
    },
    content = {
        // ここで画面の表示を作る
        MyContentScreen()
     }
)

その他

viewModelを viewModel() で取得できたり、Navigationによる表示切り替えも行えるため、やりたいことは一通り行えそうであることが感じとれます。
また、これまでに作成した既存のViewは AndroidView なるものを使用することでComposeの世界に引き込んだりもできます。

他にCompose独自に覚えることとして、remember系の関数で値を保持したり、表示更新の契機としてStateを操作したりと従来にはなかった考え方を覚えて行く必要があります。
このあたりはReactのComponentで表示を作るときに近いものを感じました。

ハマったところ

Android StudioがCanaryであったり、Composeがbetaであるためか、いくつかハマったところがありました。

  • viewModel()を使うとプレビューが表示されない
    • viewModel()を使わずにViewModelの実体を渡すか、あるいはViewModelから取得した値だけをComposableな関数へ渡す
    • プレビューを使わず、エミュレータや実機で確認するだけなら問題なし
  • 自動importがよきに行われないものがあるため毎回手動でimportを書くことになるものがあった
    • viewModel()を使うための import androidx.lifecycle.viewmodel.compose.viewModel
    • var value by remember { mutableStateOf("") } などと by を使ってStateのvalueへのシンタックスシュガーを利用する場合の import androidx.compose.runtime.getValue / setValue
      • stackoverflowの回答(*4)に助けられました
      • (3/29追記) by xxx.observeAsState を使用した場合のgetValue(※7)や by remember を使用した場合のsetValueのimportなど、一部に対応されたようです
  • BottomSheetやSnackbarの使い方のベストプラクティスがわからない
    • Textなどと同じように作ることでとりあえず表示は行えるが、BottomSheetScaffoldやSnackbarHostなるものがあるため、よりよい使い方があると思われる

さいごに

今回の記事は公式Document(*5)を一通り読んでその中のおおよそを触ったものの一部です。Composeの情報は多いため覚えきることも紹介しきることも難しいですが、触ってみた範囲ではxmlで組むより簡単に表示を構築できる印象がありました。
対応されたAndroid Strudioとともにstable版になる日が楽しみです。

Jetpack Composeを使ったチャレンジとして Android Dev Challenge (*6) なるものも開催されているので、挑んでみるのも良いと思います。

参照

*1
JetpackのLibraries
https://developer.android.com/jetpack/androidx/explorer

*2
公式Document中のConstraintLayoutの補足
https://developer.android.com/jetpack/compose/layout#contraintlayout のNote部分

*3
公式Reference
https://developer.android.com/reference/kotlin/androidx/compose/material/package-summary

*4
stackoverflowの回答
https://stackoverflow.com/questions/64951605/var-value-by-remember-mutablestateofdefault-produce-error-why

*5
公式Document
https://developer.android.com/jetpack/compose

*6
Android Dev Challenge
こちらは最終チャレンジのWeek 4
https://android-developers.googleblog.com/2021/03/android-dev-challenge-4.html

※7
Android Studio Arctic Fox Canary 12のFixes https://androidstudio.googleblog.com/2021/03/android-studio-arctic-fox-canary-12.html

誰でもわかるStoreKitTesting

誰でもわかるStoreKitTesting

f:id:kai_ios:20210304143718p:plain

はじめに

はじめまして。エブリーでiOSエンジニアをしている佐藤です。

DELISH KITCHENで、主にプレミアムサービスや課金周りを担当しています。

今回は、WWDC2020で発表されたStoreKitTestingについて紹介したいと思います。

概要

概要としては以下が挙げられるかと思います。

  • AppleStoreサーバに接続せずにローカル課金テストができる
  • ローカルでテスト商品を作れる
  • 購入トランザクションの管理ができる
  • 割引系(お試しオファー、プロモーションオファーなど)のデバッグが可能
  • プロモーションオファーはローカルの秘密鍵を作成可能
  • レシートはローカルで署名されている
  • 課金のユニットテストが可能

ローカルで実行できる課金環境がとても充実してきていますね。

次にStoreKitTestingの導入の流れを簡単に説明していきたいと思います。

Configurationファイルを作成

まずはNew FileでStoreKit Configuration Fileを選択し、作成します。 f:id:kai_ios:20210304143646p:plain

次にサブスクリプショングループを作成します。 f:id:kai_ios:20210304143653p:plain

次に課金商品を作成していきます。 選べるのは以下の3つ。

  • 消耗型
  • 非消耗型
  • 自動更新サブスクリプション

f:id:kai_ios:20210304143705p:plain

作成が終わるとこんな画面になります。 f:id:kai_ios:20210304143714p:plain

Product IDや期間などは任意で選択可能です。

オファーの作成

更にStoreKitTestingではAppleが用意している様々な購入オファーの選択も可能です。

そのひとつが、Introductory Offer(お試しオファー)です。

これは初回購入ユーザーに対してアプローチ可能なオファーになります。

選べるのは以下の3つ

  • Pay As You Go(都度払い)
  • Pay Up Front(前払い)
  • Free (無料)

f:id:kai_ios:20210304143701p:plain

2つ目がPromotional Offer(プロモーションオファー)

これは再登録者や継続ユーザーへアプローチ可能なオファーです。 詳しい実装は割愛しますが、AppleStoreConnectで作成した秘密鍵をもとに署名を作成し、StoreKitでの購入時に必要なパラメータを含めると購入可能になります。

詳しい実装方法

StoreKit Testingではローカルで秘密鍵を作成可能で、それをもとに署名を行うことで購入テストが可能になります。

f:id:kai_ios:20210304143650p:plain

残念ながらiOS14から使用可能になったもうひとつのオファーである、オファーコードはStoreKit Testingで使用することはまだできないようです。 参照

Configuration Fileを設定する

Product > Scheme > Edit Scheme > Runを開き、 以下画像のように作成したConfiguration Fileを設定します。

Schemeごとに設定可能なので、 任意のSchemeに作成したConfiguration Fileを設定することでStoreKit Testingでの購入が有効になります。

f:id:kai_ios:20210304143712p:plain

様々なデバッグ

StoreKitTestingでは様々な購入デバッグが可能です。

以下のようなものが設定可能です。

f:id:kai_ios:20210304143643p:plain

  • 既定購入ストアの設定(購入する国別ストアの選択)
  • 既定表示言語
  • タイムレート(購入有効期限の時間短縮率)
  • 購入割込のデバッグ有効化
  • トランザクションを失敗させる(エラー種別も選択可能)
  • 購入確認の表示
  • プロモーションオファーのローカル秘密鍵とKeyIDの生成
  • ローカル証明書の生成(StoreKitTestingでのレシート検証のため)

※選択できるエラー種別

f:id:kai_ios:20210304143708p:plain

またトランザクションの管理も行うことができます。

f:id:kai_ios:20210304143721p:plain

まとめ

StoreKitTestingの設定方法をかんたんにまとめてみましたがいかがだったでしょうか。

今まで開発中は実機でSandboxでの課金テストを行っていましたが、StoreKitTestingによって開発効率は上がったように感じます。 直近ではプロモーションオファー関連の開発デバッグを簡単に行うことが出来、導入のメリットを感じることができました。

課金テストの自動化など安全面でも導入の強みはあるのではないかと思いますので、 まだ未導入の方もしくはIn App Purchase実装の練習をしたい方などはぜひお試しを!

Adobe Premiere Pro エクステンションによるレシピ動画編集の効率化

Adobe Premiere Pro エクステンションによるレシピ動画編集の効率化

はじめに

DELISH KITCHENでは日々多くのレシピ動画を公開していますが、その動画は全てAdobe Premiere Pro(以下 Premiere Pro)を使用して編集しています。

今回はPremiere Proのエクステンションを作成して動画の編集効率を向上させた話をご紹介します。

これまで発生していた問題

レシピ動画にどのような材料を使っているか、どのような工程があるかは全てダッシュボード(データ管理用Webサイト)で管理しています。 動画編集者は動画データをPremiere Proに取り込み、対象レシピの情報をダッシュボードから開き、見比べながら作業していました。

動画にテロップを表示する際には、材料や工程の文章をダッシュボードからPremiere Proにコピペしながら編集作業を行っていました。

f:id:ton1517:20210224142824j:plain
肉巻き半熟卵の動画テロップ例

この作業は地味に時間がかかる上にコピペミスをしやすく、手戻りが発生したりミスが残ったままレシピ動画が公開されてしまうこともありました。

そこで、編集作業の効率化 & ミスの削減のためにPremiere Proのエクステンションを開発しました。

エクステンションの紹介

エクステンションを有効にした状態でPremiere Proを開くと以下のような画面になります。 画像右上のパネルがエクステンションの画面です。 これから編集するレシピの情報が自動的に表示されるため、自分でダッシュボードを開く必要はありません。

f:id:ton1517:20210224142935p:plain
Premiere Proでエクステンションを開いたところ

レシピのタイトルを挿入するときはタイトルの項目にある緑のボタンをタイムラインの好きな位置にドラッグ&ドロップします。 そうすると自動的にDELISH KITCHENで決められたデザインのタイトルテロップが挿入されます。 あとは表示する秒数やデザインを微調整すればタイトルテロップは完成です。

f:id:ton1517:20210224143019p:plain
タイトルテロップをドラッグ&ドロップで挿入

材料も同様に、表示させたい位置にドラッグ&ドロップすれば材料用のテロップが表示されます。

f:id:ton1517:20210224143140p:plain
材料テロップをドラッグ&ドロップで挿入

このようにタイトルや材料などのテロップをドラッグ&ドロップで動画内に挿入できるので、これまでのコピペ作業は必要なくなり、 ポチポチするだけである程度レシピ動画が作れてしまうというのがこのエクステンションの良いところです。

使用している技術

Adobe CEP

このエクステンションはAdobe CEP (Common Extensibility Platform) という技術を用いて作られています。 これはHTML5/JavaScript/Node.jsを使って様々なAdobeソフトウェアのエクステンションを開発できるというものです。

詳しくは以下のGitHubや記事で詳しく解説されています。

エクステンションの画面はChromium Embedded Frameworkというアプリケーションに埋め込んで使用するChromiumフレームワークを用いて表示しているため、 一部制限はありますがほぼ通常のChromeでHTML5/JavaScriptを実行するのと遜色ありません。 またNode.jsが実行できるためローカルファイルの読み書きも行えます。

AdobeソフトウェアのバージョンによってAdobe CEPのバージョンも変わり、それによって使えるAPIやChromium / Node.jsのバージョンも決まってくるため、 事前にサポートするバージョンを確認しておいた方が開発がスムーズになります。

参考: CEP-Resources/CEP 10.0 HTML Extension Cookbook.md at master · Adobe-CEP/CEP-Resources

Nuxt.js

Chromiumの上でHTML5/JavaScriptが実行できるとなると、ほぼWebサイトを作成するのと変わりません。 そのため、このエクステンションはNuxt.jsを使用しています。 (当初は素のVue.jsだったのですが、最近Nuxt.jsにリプレイスしました)

DELISH KITCHEN WEB を構成する技術のお話 でも紹介したように、 DELISH KITCHENのWebサイトにはNuxt.jsを使用しています。またレシピ管理用のダッシュボードでも同様にNuxt.jsを使用しています。

Nuxt.jsはサーバーサイドレンダリング(SSR)が特徴として挙げられがちですが、SSR以外にもページのルーティングルールやコンポーネント、プラグインの設置場所などが全て定められているというのが大きな特徴で、 Nuxt.jsで開発したことのあるWebエンジニアであればすぐにプロジェクトの構成が把握できるのが強みです。 そのためこのエクステンションでもNuxt.jsを使うことによって自分以外のエンジニアがエクステンションを開発する際にもプロジェクト構成の把握が容易になり、 共通のライブラリやプラグインが使用できるため開発がスムーズになります。

工夫した点

編集対象のレシピ情報を自動的に表示する

動画を編集する際に、毎回ダッシュボードから編集対象のレシピを開くのは地味に面倒な作業なので、Premiere Proを開くと自動的にレシピの情報が表示されるようにしました。

仕組みは単純で、以前からレシピ編集のルールとしてPremiere Proのプロジェクトファイルには <レシピID>_<レシピタイトル>.prprojというような命名規則で名前をつけることが決まっていたので、 Premiere ProのAPIでファイル名を取得し、正規表現でレシピIDを抜き出してからDELISH KITCHENのAPIでレシピ情報を取得し表示しています。

ドラッグ&ドロップでテロップを挿入

なるべく直感的にテロップを挿入できるようにしたかったため、ドラッグ&ドロップで挿入できるようにしました。 ドラッグ&ドロップ自体は通常のWebと同じくdragイベントをハンドリングしdataTransfer.setData()でテロップのデータを渡せば良いのですが、setData()の第一引数に渡すformatは"com.adobe.cep.dnd.file.0"という文字列でなければいけません。 (複数データを渡す場合は最後の数字をインクリメントしていく)

参考: Samples/ext.js#L84 Adobe-CEP/Samples

PRTL

ドラッグ&ドロップでテロップを挿入、と言いましたが、実際には何のファイルをドラッグ&ドロップで渡しているかというと、PRTLというフォーマットのファイルを渡しています。 これは現在Premiere Proでレガシータイトルと呼ばれているテロップのフォーマットで、XML形式のファイルになっています。

テンプレートとして使用するPRTLファイルは予めエクステンション内に保存してあり、 材料などのテロップ挿入ボタンがドラッグされた瞬間にテンプレートのPRTLを読み込み、指定された箇所の文字列を材料名で置き換えます。再度PRTLファイルとして書き出した後にdataTransfer.setData()にそのファイルパスを指定すると、 ドロップした場所にそのPRTLファイルがテロップとしてインポートされ表示されるという仕組みです。

余談

Premiere Proにはレガシータイトル以外にもエッセンシャルグラフィックスというテロップの機能があります。 こちらもテンプレートがありAPIでPremiere Proに取り込むことができるのですが、若干扱いづらく、XML形式であることや直感的にドラッグ&ドロップで取り込めるという点でPRTLを採用しました。

ただし、PRTLはフォーマット仕様が公開されておらず(公開されていたらどなたか教えて下さい)、独自にパースする必要があります。 また、Premiere ProでテロップをPRTLファイルとして書き出せるのはCS6までで、それ以降のバージョンでは書き出し機能は削除されてしまいました。 このような状況で、将来的にPremiere Proがレガシータイトルをサポートしなくなる恐れもあるため、できればエッセンシャルグラフィックスを使ってテロップを挿入できるようにしたいところです。

エクステンションのパッケージング

Adobe CEPのエクステンション自体はPremiere Proのエクステンション用のディレクトリに配置すれば使用できるのですが、動画編集をするスタッフに毎回その場所に配置してもらうのも手間がかかります。 そこで、エクステンションをインストーラーでインストールできるようにしました。 全員Mac上でPremiere Proを使用するので、インストーラーとしてpkgファイルを生成します。

パッケージングの詳細や使用したコマンド、npmパッケージなどは以下を参考にしてください。

パッケージングを手動で行うのも面倒なので、GitHub上でPullRequestをmasterにマージした際にCIでパッケージングし、 そのpkgファイルをtcnksm/ghrを使用してGitHub Releasesに自動的にアップロードするようにしました。

これでpkgファイルをGitHub Releasesからダウンロードして開けばMacでおなじみのインストーラーが起動し、エクステンションをインストールできるようになります。

f:id:ton1517:20210224143216p:plain
エクステンションのインストーラー

まとめ

このエクステンションを使うことによってPremiere Pro内でテロップの挿入が完結できるようになりました。 また、ドラッグ&ドロップでテロップを非常に簡単に挿入できるようになり、コピペミスを減らすことができました。 もちろん動画編集作業はこれだけで終わりではないのですが、地味に時間のかかっていた作業を減らすことができ、編集効率を向上させることができました。

このPremiere Proのエクステンションは2018年に作成したものですが、3年弱経った現在も毎日使われています。 自分が作ったものが毎日使ってもらえているというのは開発者冥利に尽きる思いですね。

DELISH KITCHENのサービスも毎日沢山の方に使っていただくため日々開発に励んでいます。

これからもDELISH KITCHENをよろしくお願いします。

MAMADAYS iOSアプリについて

f:id:nanakookada:20210203144149p:plain

はじめに

MAMADAYSにはiOSとAndroidのアプリがあります。 Flutterなどのクロスプラットフォーム開発ではなく、それぞれネイティブで開発しています。

この記事ではMAMADAYSのiOSアプリの全体的な構成を紹介します。 全体の雰囲気を掴んでもらうことを目的とし、細かい採用技術はまた別の機会に紹介できればと思います。

MAMADAYSアプリの機能

MAMADAYSアプリには大きく次のような機能があります。

メディア

MAMADAYSには動画を含む数千本の記事があり、ユーザーさんの状態やお子さんの月齢に合わせて適切な記事をおすすめする仕組みがあります。 リリース当初は記事を WKWebView で表示していましたが、表示速度向上などのためにネイティブに変更しています。 動画再生には AVPlayer を用いていて、自動再生処理や待ち時間短縮のために、それなりに複雑な非同期的な制御が必要になっています。

f:id:nanakookada:20210205173707p:plain

育児記録

お子さんの睡眠や授乳などを簡単な操作で記録し、グラフでわかりやすく振り返ることができる機能です。 この機能のみ、 Firebase Cloud Firestore を利用しています。 Firebase Cloud Firestore の採用には以下のような利点がありました。

  • サーバーの実装が不要
  • クライアントの実装が簡単
  • 非同期通信で待ち時間なし
  • 入力した記録をパートナーにリアルタイムに同期できる

リリース当初の時間が無い中では、工数削減、品質向上に非常に役立ったと思います。 ただし、育児記録機能と他機能の連携を進める上で障害になってきているため、将来的には独自のAPIに置き換えることになりそうです。

f:id:nanakookada:20210205173744p:plain

離乳食

離乳食の進み具合を記録したり、時期にあった調理法を探せる食材リスト機能があります。

f:id:nanakookada:20210205173810p:plain

カレンダー

家族の予定を一つのカレンダーで共有できます。 また、思い出として写真をアップロードし、簡易的なアルバムのようにする機能があります。

パートナー共有

上記全ての機能はデータを家族内で共有できるようになっています。

アーキテクチャー

アーキテクチャーはMVVMとしています。 ただし ViewController から ViewModel の接続はメソッドコール、 ViewModel から ViewController の接続はクロージャーで、Rx等によるバインディングを用いていないので一般的なMVVMとは異なるかもしれません。 Viewはほぼ UITableView で構成されており、Viewの更新は UITableView のリロードですることが多いため、個別のデータをバインディングするメリットを感じなかったためにこのような構成になっています。

また、ViewControllerの階層化を積極的に使っています。 コンテナを使って階層化することによってView Controllerの肥大化を防ぐようにしています。

まとめ

MAMADAYSのモバイルアプリは2019年10月にリリースして以来コンスタントにアップデートを続け、離乳食、カレンダー、妊娠週数と大きめの機能を追加してきました。 今後もユーザーさんの声を聴きながら進化を続けていきます。 開発者としてはコードをできるだけシンプルで変更に強い状態に保つことで、開発速度と品質でサービスに貢献したいと考えています。

Nxを使ってnpm projectをmonorepo管理した話

DELISH KITCHEN RS事業部では、小売向けにサイネージやチラシ等のサービスを提供しています。 従来は、そのサービスの管理が出来るWebアプリのみ運用していたのですが、新たに広告配信設定用のWebアプリが必要になりました。 そこでNxを使って、2つのアプリをmonorepoで管理し、コードの共通化を計りました。

Nxとは

Nxはmonorepo用の拡張可能な開発ツールセットです。堅牢なCLI、キャッシュシステム、依存性管理などを提供すると共に、Jest、Cypress、ESLint、Prettierなどのモダンなライブラリの統合をサポートしています。元GoogleのAngularチームにいたメンバーによって創設されたNrwlが開発しており、Googleは全てのプロジェクトをmonorepoで管理しているという有名な話がありますが(詳細は知りません)、それと似た開発体験を提供することを目的に開発されているそうです。

Nxへの移行

RS事業部で開発しているWebアプリはAngularで作られており、それをまずNxに移行しました。

f:id:yukiya-takagi:20210128142040p:plain
従来のディレクトリ構成

NxはAngularをサポートしているので、移行自体は簡単でした。 まずNxで新しくworkspaceを作成します。

npx create-nx-workspace --preset=angular

その後、既存のアプリのコードをapps以下に配置し、angular.jsonやtsconfig.json、tslint.jsonなどの設定ファイルを修正し、既存のアプリで使用していたサードパーティのライブラリ(dayjsなど)を新しいworkspaceに追加して、移行を完了しました。

f:id:yukiya-takagi:20210128142201p:plain
現在のディレクトリ構成

※ 現在のcreate-nx-workspaceは、テストフレームワークにデフォルトでJestとCypressが選択されており、AngularデフォルトのKarma、Protractorを使用したい場合は、別途以下のコマンドでアプリを作成する必要があります。

nx generate @nrwl/angular:app myapp --unit-test-runner=karma --e2e-test-runner=protractor`

ライブラリの作成

複数のアプリから共通のコードを使用するために、ライブラリを作成します。

nx generate @nrwl/angular:lib shared

上記のコマンドでlibs配下にsharedディレクトリが作成されます。

今回は例としてSampleComponentをライブラリに作成します。

nx generate component sample --project=shared

作成したら、shared.module.tsのexportsにSampleComponentを追加します。 次に、アプリからSampleComponentを使用するために、tsconfigにパスを追加します。

{
  ...
  "compilerOptions": {
    ...
    "paths": {
      "@lib/shared": ["libs/shared/src/index.ts"],
      "@lib/shared/*": ["libs/shared/src/lib/*"]
    },
    ...
  },
  ...
}

あとは使用したいモジュールでimportすると、使用可能になります。

import { SharedModule } from '@lib/shared';

@NgModule({
  imports: [SharedModule],
  bootstrap: [AppComponent]
})
export class AppModule {}

また、直接SampleComponentをimportしたい場合は、以下のコードで可能です。

import { SampleComponent } from '@lib/shared/sample/sample.component.ts'

CSSの共通化

上記で作成したsharedライブラリに共通のCSSも置いて、使えるようにします。 場所はどこでもいいのですが、私はlibs/shared/src/stylesにファイルを配置しています。

html,
body {
  height: 100%;
}

body {
  margin: 0;
  font-family: 'Helvetica Neue', Arial, 'Hiragino Kaku Gothic ProN', 'Hiragino Sans', Meiryo, sans-serif;
}

そしたら、angular.jsonの、このスタイルを適用したいアプリの箇所に以下を追加します。

"app": {
  "projectType": "application",
  ...
  "architect": {
    "build": {
      ...
      "options": {
        ...
        "styles": [
          "libs/shared/src/styles/styles.scss", // この部分
        ],
        ...
      }
    }
  }
}

また、partialファイル(_mixin.scssなど)をsharedに置いて参照することも可能です。 これも好きな場所にファイルを配置して、angular.jsonでパスを指定するだけです。

 "app": {
  "projectType": "application",
  ...
  "architect": {
    "build": {
      ...
      "options": {
        ...
        "stylePreprocessorOptions": {
          "includePaths": ["libs/shared/src/styles/partials"], // この部分
        },
        ...
      }
    }
  }
}

ここで注意なのが、指定するのはファイルパスではなくディレクトリパスということです。こうしておくことで、partials以下にあるファイル(_mixin.scss)を@import 'mixin'という形で使うことができます。

CI/CD

monorepoにするとCI/CD周りも変わってきます。おそらく多くの人が、変更があったアプリ、またはライブラリだけをテスト、デプロイしたいと考えると思います。Nxはその希望を叶えてくれます。Nxにはaffectedコマンドがあり、変更の影響があるプロジェクトのみに対してテスト、ビルドを実行する機能があります。

CI/CDはGithub Actionsで行っていて、実際のワークフローを例に紹介したいと思います。Github ActionsはPull Requestを作った時とdevelopmasterブランチにマージされたタイミングで走るように設定しています。

例えば、Pull Requestを作った時に走らせるビルドは以下のように設定しています。

name: build
on: pull_request
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v1
        with:
          node-version: '12.x'
      - name: Run cache/restore node_modules
        uses: actions/cache@v1
        with:
          path: node_modules
          key: v1-${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}
      - name: Run build
        run: make affected-build BASE=${{ github.event.pull_request.base.sha }} // nx affected:build --base=${BASE} を呼んでるだけ

ここで、affectedはbase optionでブランチやコミットIDを指定でき、baseとHEADの差分から、影響のあるプロジェクトを判断します。その仕様から、actions/checkout@v2ではfetch-depth: 0を指定することで、コミット履歴を全部取得するようにしています。

またmasterにマージされた際のデプロイは以下のように設定しています。

name: deploy
on:
  push:
    branches:
      - master
jobs:
  build:
    ...

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Run cache/restore dist
        uses: actions/cache@v1
        with:
          path: dist
          key: v1-${{ runner.os }}-dist-${{ github.run_number }}
      - name: Run deploy
        run: |
          app_paths="dist/apps/*/"
          if ! ls -d $app_paths &>/dev/null ; then
            exit 0
          fi
          for app_path in $app_paths; do
            app=$(basename "$app_path")
            if [ "$app" == "appName1" ]; then
            elif [ "$app" == "appName2" ]; then
            fi
          done

差分があるもののみデプロイするという仕組みはNx自体にはないので、buildフェーズで生成されたものをデプロイするというスクリプトを書いて対応しています。

現在のデプロイの仕組みだと、masterに入ったものは全部対象になってしまうので、リリース前に全プロジェクトの確認が必要になってしまいます。またmasterに入ってもリリースのタイミングは調整したいこともあるでしょう。monorepoにして一番の課題で、依然他に良いフローがないか検討中の部分です。

まとめ

今回はNxを使ってnpm projectをmonorepo管理した話をしました。Nxを使ったComponentやCSSの共通化、CI/CDの運用とかは普段聞く機会がないので、誰かの参考になれば幸いです。