7

Yeoman (www.yeoman.io) を発表する Paul Irish の講演を見て、継続的なビルド環境を実行するという概念に夢中になりました。Yeoman の招待を待つだけでは満足できないので、Grunt と Brunch を試してみました。どちらも簡単にインストールでき、最小限の労力で新しいプロジェクトを立ち上げて実行できます。

既存のプロジェクトをいずれかのプラットフォームに移行する方法がわかりません。私のプロジェクトでは、単一の名前空間を使用し、モジュールに 2 つの規則 (1 つはユーティリティ用にインスタンス化するため) を使用します。それぞれの規則は、インスタンスまたは名前空間にエクスポートする自己実行型の匿名関数にラップされています。

少なくとも 200 個のモジュールと、名前空間への単純なヘルパー関数のエクスポートが多数あります。そのため、コンソールを使用してこれらを grunt/branch プロジェクトで作成し、各モジュールを個別に手動でインポートするのはまったく効率的ではありません。さらに、少なくとも 15 種類のサードパーティ JavaScript ツールを使用しています。これらをどのように持ち込むかは私には明らかではありません。

大規模な既存のプロジェクトを取得し、最小限のリファクタリングと任意のサードパーティ ツールのサポートで Grunt/Brunch に移行する最も効率的な方法は何ですか?

更新: 2 つのうち、Brunch の方が対処しやすいことがわかりました。標準の「スケルトン」(つまり「テンプレート」) を使用する場合は、{変更を加えたいフォルダー内のコマンドラインから} 「ブランチ 新規 [プロジェクト名] --skeleton git://github.com/brunch を実行します。 /simple-js-skeleton.git") 純粋な JS の場合、実際には非常に応答性の高い新しいフォルダー構造が得られます。「app」(独自のコード) または「vendor」(サードパーティ) フォルダーにドロップしたものはすべて、ファイル編集時に (「ブランチ ウォッチ」を実行すると) 自動的に再コンパイルされます。

これは素晴らしいことです。ドキュメントによると、ベンダー スクリプトがコンパイルされ、Brunch config.coffee ファイル (JSON テキスト ファイル) から一緒に連結される順序を制御します。このファイルへの変更は効果がないように見えるため、他のプラグインを期待するプラグインからサードパーティの競合状態が発生します。

さらに、独自のコードを自動作成された「アプリ」フォルダーにドロップすると、コードの自動コンパイルされたリアルタイムの編集バージョンが得られます。しかし、アクセスできません。Brunch はウィンドウ オブジェクトを難読化するため、window.myNameSpace への最初の名前空間宣言が失敗し、その後の名前空間へのライブラリ呼び出しもすべて失敗します。これは、ドキュメントが見つからない Brunch のモジュール システムと関係があります。

名前空間クラスを「ベンダー」フォルダーに配置することでこれを解決しました。これにより、ウィンドウオブジェクトに確実にアタッチされました。ただし、競合状態が発生しています。私の名前空間は、すべてのモジュールで常に使用できるわけではありません。

問題は次のとおりです。

内部ライブラリと外部ライブラリをすべて Brunch プロジェクトにコピーしたら、それらを適切な順序で読み込むようにアプリを構成するにはどうすればよいでしょうか?

4

2 に答える 2

7

これはちょっとしたオーパスですが、私はついにそれを理解しました。Brunch を使い始めたとき、最初のステップであるディレクトリ構造をインポートする方法が明確ではありませんでした。明らかになる前に、ドキュメントを数回通過する必要がありました。

  1. Execute brunch new MyAppName -s https://github.com/damassi/Javascript-App-Skeleton。これにより、スケルトン フォルダー構造と config.coffee ファイルが生成されます。
  2. 私にとって、この構造に関連する唯一のフォルダーは、「app」(CSS、JS、および HTML の生の src コンテンツ)、「public」(コンパイルされたコンテンツの宛先および NodeJS サーバーにサービスを提供する場所)、および「vendor」(サードパーティのファイルの場所)。
  3. Brunch は、ディレクトリ構造のルートに config.coffee ファイルを次の内容で作成します。files: javascripts: defaultExtension: 'js' joinTo: 'javascripts/app.js': /^app/ 'javascripts/vendor.js': /^vendor/ order: before: [ 'vendor/scripts/console-helper.js', 'vendor/scripts/jquery-1.7.1.min.js' ]
  4. このオブジェクトの「joinTo」プロパティは私を混乱させましたが、「javascripts」は実際には「クライアント側コード」の単なるマスクであり、「apps.js」は実質的に「すべての *.js ファイルを取得するための呼び出し」であることに気付きましたフォルダー「アプリ」、再帰的に」。
  5. これが明確になったら、あとはコンテンツを「アプリ」にドロップするだけです。*.html ファイルと画像ファイルを「assets」サブフォルダーに配置し、すべての JavaScript コンテンツを lib に配置しました。
  6. この時点で、ブランチ ビルドとブランチ ウォッチを実行すると、プロジェクトが起動して実行され、変更を加えるとリアルタイムでコンパイルされ、ブラウザでライブ リロードされます。

Brunch は、ステップ 6 を使いやすいという点で Grunt よりも優れていますが、私にとって失敗したのは、Brunch でのコンパイルの性質です。すべての JavaScript ファイルは CommonJS モジュールにラップされ、モジュール名は相対パスとファイル名 (「lib/core/ajax」など) に基づいています。CommonJS の哲学は私には向いていません。CommonJS を使用するためにライブラリをリファクタリングする作業は膨大です。

では、Grunt に戻ります。プロジェクトをBrunchにインポートする方法を理解したら、Gruntへのインポートは簡単でした. 私は Windows を使用しているため、すべての grunt 呼び出しは grunt.cmd を使用します。

  1. 呼び出しgrunt init:jquery(これはどこでもかまいません。作成したディレクトリ構造を既存のプロジェクト フォルダーに移動しました)
  2. Brunch と同様に、自動生成されたディレクトリ構造と構成ファイル (grunt.js) を取得しますが、はるかに薄いです。Grunt の構成は次のようになります。concat: { dist: { src: ['<config:lint.files>'], dest: 'dist/<%= pkg.name %>.js' } }, min: { dist: { src: ['<banner:meta.banner>', '<config:concat.dist.dest>'], dest: 'dist/<%= pkg.name %>.min.js' } }, qunit: { files: ['test/**/*.html'] }, lint: { files: ['grunt.js', 'src/**/*.js', 'test/**/*.js'] }, watch: { files: '<config:lint.files>', tasks: 'lint qunit' }
  3. これは最初は少し異質に見えましたが、実際には非常にエレガントです。「min」プロパティは、Web アプリが提供する最終的な、連結され、lint され、縮小されたファイルを定義します。そのソース値は '' です。これは、lint のファイルのプロパティ値から派生した concat オブジェクトの dist dest プロパティ値の値を調べる Grunt マジックです。そのため、lint レベルで、リント、連結、縮小、宛先への出力を行うリソースを定義します。
  4. この部分が配置されたら、ビルド、監視、およびサーバーの部分を配置するために、少し追加の作業を行う必要があります. うなり声では、サーバーの実行が終了すると終了します。つまり、grunt サーバー タスクを実行すると、サーバーが起動し、他に実行するタスクがなく終了します。
  5. 私の最初の間違いは、watch.task = 'server lint qunit' を設定して、サーバー タスクをウォッチのタスクにバンドルしたことです。これは、ソースに加えた最初の変更では機能しますが、2 回目の変更では、同じポートでサーバーの 2 番目のインスタンスを起動しようとして失敗します。代わりに、タスクgrunt.registerTask('dev', 'server watch qunit');を登録して grunt dev を呼び出して、リアルタイムの継続的なビルドでサーバーを実行できます。
  6. 次に、私の HTML コンテンツは、サーバー側のインクルードに依存してページを組み立てました。ノードでこれを機能させる方法がわかりませんでした。クライアント側のインクルードを使用しても機能し<object/>ません。コンテンツ (私の場合はさまざまな要素) を Iframe に挿入するため<script/>、<link/>もちろんモジュール パターンが壊れます (私の名前空間は、iframe の window オブジェクトとは異なる window オブジェクトにあります)。幸いなことに、grunt の concat オブジェクトはマルチタスクであり、何でも連結できます。そのため、HTML ファイルを concat に追加すると、シングルページ アプリの準備が整いました。
  7. 次に、ノード サーバーが IIS インスタンスとは異なるポートで実行されているため、クロス ドメイン ajax の問題があります。このSO 記事は正しい道を歩み始めましたが、IIS の既定のコンテンツ ヘッダーに次の変更を加える必要がありました。Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: X-Requested-With, X-Prototype-Version, Content-Type, Origin, Allow Access-Control-Allow-Methods: PUT, GET, POST, DELETE, OPTIONS Access-Control-Allow-Origin: http://localhost:88
  8. 最後に、デフォルトの AJAX ハンドラーに jQuery を使用しているため、これを ajax オプションに追加する必要がありました。xhrFields: { withCredentials: true }
  9. 明らかに、ここにはセキュリティへの影響があります。しかし、これは私の開発環境にのみ影響し、本番環境にはプッシュされないため、問題ないと思います。
  10. 大事なことを言い忘れましたが、Uglify を使用して縮小化のエラーをデバッグするのに 1 時間費やしました。Visual Studio は BOM を常に挿入することを主張しているため (「UTF-8 With Signature」は婉曲表現です)、UTF-8 Castはこれを迅速に修正します。

このすべてを理解すると、Grunt はかなりうまく機能しているように見えます。この新しい連続ビルド環境で実際の開発プロセスをテストする機会はまだありません。しかし、これが開始できるようになるまでに必要なことです。

于 2012-07-15T02:58:56.840 に答える
3

config.coffee実際のjs / coffeescriptではなくjsonではありませんが、順序の編集は機能するはずです。正確な設定順序でブランチ バグトラッカーで問題を開くことはできますか?

windowグローバル変数ではなくモジュールを使用するようにアプリを書き直す簡単な方法はないと思います。ちなみに、グローバルは悪趣味と見なされています。しかし、あなたのソリューションはうまくいく可能性があります。

于 2012-07-13T08:50:50.727 に答える