Trigger.io を使用して継続的に開発し、ブラウザーまたはシミュレーターでテストしたいすべてのファイル変更でフォージ ビルド手順を回避する方法があるかどうかを知りたいです。
3 に答える
ビルド フェーズでは、ソースにいくつかの変更を加えて forge.* API を有効にします。したがって、src
ディレクトリ内の未加工ファイルを使用しようとしても機能しません。
ディレクトリ内のファイルを直接変更したくなるかもしれませんがdevelopment
、これはかなり悪い考えです。
変更が発生したときにビルドを自動的に開始するファイル システム ウォッチャーを追加する中期ロードマップを計画しています。
forge build && forge run PLATFORM
それまでの間、私は数秒しかかからない傾向があるものを使用しています...
私は同じ問題に直面していました.watchrとwatchを使用して、ソースファイルに変更を加えるたびに自動的に再構築する実用的なソリューションがあります. アプリの「Web」バージョンを実行している場合は、ソース ファイルに変更を加えて直接ブラウザーに移動し、ビルドにかかる時間に応じて、変更の効果をかなり迅速に確認できます。
前提条件: Ruby、watchr、Unix 'watch'、およびターミナル。
- gem インストール ウォッチャー。
- watchr 用の新しい ruby ファイルを作成して、どのファイルを監視し、変更を検出したときに何をすべきかを把握します。ファイルに「my_watch.rb」という名前を付けました: https://gist.github.com/3153167
- 2 つのターミナルを開きます。ターミナル 1 は watchr を実行し、ターミナル 2 は 'forge build ...' を実行します。
- ターミナル 1 で 'watchr my_watch.rb' を実行して、my_watch.rb へのパスが正しいことを確認し、設定に従って my_watch.rb を編集したことを確認して、watch(...) 内のパスが対象のファイルを反映するようにします。見た。私の例では、my_watch.rb スクリプトと同じディレクトリ (およびその下) にあるすべてのファイルを監視します。私の例に合わせて、src フォルダーから直接 watchr my_watch.rb を実行したい場合は、Trigger.io アプリの 'src' フォルダーに my_watch.rb を配置できます。また、環境を反映するためにブロック内のシェル コマンドとパスを更新する必要はありません。繰り返しますが、私の例では 'my_watch.rb' は 'src/' 内にあるため、変更が検出されると、1 つ上のディレクトリに移動して 'forge build' を呼び出します。
- 私は自分のアプリの「ウェブ」バージョンで積極的に開発する傾向があるので、端末 2 を開いて自分のフォージ プロジェクト ディレクトリと「フォージ ラン ウェブ」を開くことができます。シミュレーターやデバイスでテストしているときは、変更を確認するたびに forge ビルドを実行する必要があります。ただし、変更を加えるとすぐに watchr がビルドを開始し、それがかなり迅速に行われるため、通常は forge ビルドが完了するのを待つ必要はありません。
これが理想的な解決策ではないことはわかっていますが、これまでのところ、最初に「Web」バージョンで新機能を開発し、次にモバイル バージョンに実装することは非常にスムーズでした。ビルド後に「Web」バージョンを強制終了する必要はありませんでしたが、運が良かっただけかもしれません。キーボード ショートカットに慣れていれば、モバイル バージョンをテストするたびにビルドを実行することはまったく問題ありません。XCode では、ネイティブ iOS アプリを作成するときにソース コードに変更が加えられた後にビルドして実行することができるため、このビルド ステップを必要とするのは Trigger だけではないと思います。
これが役に立ち、私の答えが私と私のセットアップにあまり具体的でないことを願っています。
完璧ではありませんが...これは私にとってはうまくいきます。
開発/ウェブに入る
rm src
ルートsrcへのリンク、つまりln -s ../../src src
all.jsをweb/forgeからコピーして、index.htmlに追加します
すなわち
nodemonweb.jsを開始します
ブラウザで開く。
Web以外のビルドの場合はall.jsスクリプトタグをコメントアウトする必要があることに注意してください。