js django-projectのGulpでいくつかのトリックを収集する方法

みなさんこんにちは！



これはガイドではありません。大規模なDjangoプロジェクトで、jQueryスクリプトのいジャンクから、gulpとbrowserifyを使用して、AngularJS上の複雑なフロントエンドアプリケーションのアセンブリと縮小に徐々に取り組んできた経験を共有しています。

背景

多数のレガシーコード、10億の依存関係、および公式のフロントエンド開発者のいないチームを含む大規模な長期Djangoプロジェクトがあります。 どういうわけか私は次第にjsに夢中になり、フロントエンドに関わるようになり、今ではすでに作業時間の半分以上がかかっています。



私たちのプロジェクトのフロントエンドの歴史（それに応じて、js開発者としての私の開発）には、3つの大きな段階があります。

jQueryは私たちのすべてです

これは、いくつかのjQueryメソッドをマスターし、セレクターをマスターし、アニメーションを使用してページ上の要素を表示/非表示にすることを学んだ期間でした。 すべての新参者はこれを経験し、誰もがどのように見えるかを知っています：各機能は個別のファイルであり、大きなページには多数のスクリプト接続があり、システムはありません-各スクリプトはそれ自体のためであり、彼らが言うようにすべての結果があります。 ベンダーライブラリを格納する特定の場所はありませんでした。次の各開発者は、自分が望む場所に新しいライブラリを投げました。 私が自分で書いたものすべてに加えて、私の前に書かれたたくさんの古いスクリプトがありました。

ノックアウト+ RequireJS

管理パネル用に、より複雑なインターフェース、ウィザード、その他のものを作成する必要がありました。 この時点で、jQueryは万能薬ではなく、コードを何らかの形で整理する必要があることが理解されました。 KnockoutとRequireJSが助けになりました。 RequireJSでは、コードをモジュールに分割し、依存関係を指定し、異なるページでモジュールを再利用し、各アプリケーションの通常のファイル構造を構築できました。 少なくとも何らかのシステムが登場しました。すべてのライブラリへのパスを持つRequireJSの構成ファイルが作成され、すべてのノックアウトページで使用され、すべてのベンダーライブラリが1か所に収まりました。 問題は1つだけでした。テンプレートに接続されているスクリプトは1つだけで、残りの依存関係はRequireJS自体によって引き伸ばされ、モジュールファイルが非常に小さいため、サーバーへのpingがダウンロード時間よりも長くなりました。 私はしばしばこの問題を指摘し、さまざまな解決策を提示しましたが、当局の対応は常に同じでした。「これは管理パネルです。 これは重要ではありません。 これに時間を無駄にしません。」

AngularJS + Gulp + Browserify + Uglify

最後に、手がカスタマーエリアに到達しました。トリッキーなインターフェイスとUX要件です。 スクリプトの読み込みの問題を無視することはすでに不可能でした。 当時、私はすでにフロントエンドのビルドスクリプトを使用してNodeJSで開発した経験を積んでいます。 RequireJSの構成ファイルとベンダーライブラリの体系的なダンプを涙なしで見ることができなくなりました。



プロジェクトの一般的な仕組みについて少し説明します。 各djangoアプリケーションには独自の静的フォルダーがあり、開発中にdjango devサーバーはこれらのフォルダー内のページに接続されたスクリプトを探します。 デプロイメント中に、本番環境でcollectstaticが作成されます。これにより、1つのフォルダー内のすべてのファイルが収集され、Webサーバーからファイルが返されます。 異常なことは何もありません。



私は次のものを手に入れたかった：

• フロントエンドの通常のパッケージマネージャー。
• 再利用可能なモジュール形式の通常のコード形式。
• 1つのファイルのアセンブリjs-applicationとその縮小。

質問が発生しました-通常のワークフローを妨げず、NodeJS（「Pythonistsチームの新しい言語」と呼ばれる）とそのユーティリティの新しい依存関係でボスを怖がらせないように、これをプロジェクトにねじ込む必要がありますか？



jsコードを使用したすべての操作（アセンブリ、ミニファイ）はコミットの前に行われ、完成したパッケージは対応するdjangoアプリケーションの静的フォルダーにコピーされ、そこから接続されることになりました。 したがって、展開プロセスは変更されず、実稼働環境での新しい依存関係はありません。

私たちは本当の道に着手します

環境

したがって、最初に必要なものは次のとおりです。

• nodejs ;
• gulp-アセンブリタスクを説明します。
• npm-アセンブリに必要なパッケージをインストールします。
• bower-フロントエンドに必要なパッケージをインストールします。

次のように、システムにグローバルにインストールする必要があります コンソールユーティリティが必要です。 幸いなことに、Vagrantで開発しているので、適切なシェフレシピを彼の設定に追加しました。 プロジェクトのルートにインストールした後、 npm initとbower initを実行し、必要な最小限のパラメーターを設定する必要があります。出力はpackage.jsonとbower.jsonになります。 環境を準備する最後のステップは、 .gitignoreにnode_modules /およびbower_components /を導入することです。これは、アセンブリ全体が開発中に直接行われるためです。



bowerとnpmを使用してパッケージをインストールする場合、パッケージ情報がbower.jsonとpackage.jsonにそれぞれ保存され、他の開発者がnpm installとbower installを実行するだけで簡単に環境を上げることができるように、-save-dev引数を使用することを忘れないでくださいプロジェクトのルート。

ディレクトリ構造

jsアプリケーションのソースコードをプロジェクトのルートにある別のディレクトリに保存することにしました。 最初は、アセンブリ中にその場でディレクトリ構造を分析したかったのですが、遅かれ早かれ、すべてのスマートアナライザーには、松葉杖が必要なタスクがあると考えたため、これらすべてのアプリケーションを記述する構成を作成することにしました。 そのため、 config-spa.jsファイルがプロジェクトのルートに表示されました。

module.exports = { apps: { 'appname': { //  js- main: 'app.js', //    path: './spa/dj-app/appname/', //    bundle: 'appname.min.js', //    dest: './dj-app/static/dj-app/js/', //       django- watch: ['./spa/dj-app/appname/**/*.js'] //  glob-     (    ) }, ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• spa / -すべてのjsアプリケーションが配置されるディレクトリ
• dj- app-アセンブルされたパッケージが使用されるdjangoアプリケーションの名前

したがって、スクリプトがどのアプリケーションに属しているかを簡単に理解できます。 一般モジュールは、commonという名前のディレクトリに配置されます。

gulpfile.js

小規模の場合-アセンブリのタスクの説明はそのままです。 一般に、結果は標準のgulpfileでしたが、誰かに役立ついくつかのトリックがあります。

コマンドライン引数の解析と最初のトリック

いくつかのアプリケーションがあるため、どのアプリケーションをビルドする必要があるのか​​を示すか、すべてを再構築する必要があることを示す必要がありました。

別の引数は、デバッグ中に通常のスタックトレースを表示できるように、アプリケーションの縮小をキャンセルするフラグです。



トリックは何ですか？ 第一に、引数を別のタスクとして解析し、他のタスクの依存関係で示すことができるという事実と、第二に、解析された引数がグローバル変数に格納されるため、他のタスクからいくつかのタスクを呼び出すときに、同じ設定で動作します。

 //   , .     var config = require('./config-spa'), argv = {parsed: false} gulp.task('parseArgs', function() { // prevent multiple parsing when watching if (argv.parsed) return true // check the process arguments var options = minimist(process.argv) if (_.size(options) === 1) { printArgumentsErrorAndExit() } //   ,     var apps = [] if (options.app && config.apps[options.app]) { apps.push(options.app) } else if (options.all) { apps = _.keys(config.apps) } if (!apps.length) printArgumentsErrorAndExit() argv.apps = apps // dev - ,   if (options.dev) argv.dev = true argv.parsed = true }) function printArgumentsErrorAndExit() { gutil.log(gutil.colors.red('You must specify the app or'), gutil.colors.yellow('--all')) gutil.log(gutil.colors.red('Available apps:')) _.each(config.apps, function(item, i) { gutil.log(gutil.colors.yellow(' --app ' + i)) }) // break the task on error process.exit() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ビルドアプリケーション

 function bundle() { return through.obj(function(file, enc, cb) { var b = browserify({entries: file.path}) file.contents = b.bundle() this.push(file) cb() }) } gulp.task('build', ['parseArgs'], function(cb) { var prefix = gutil.colors.yellow(' ->') async.each(argv.apps, function(app, cb) { gutil.log(prefix, 'Building', gutil.colors.cyan(app), '...') var conf = config.apps[app] if (!conf) return cb(new Error('No conf for app ' + app)) gulp.src(path.join(conf.path, conf.main)) .pipe(bundle()) .pipe(gulpif(!argv.dev, streamify(uglify()))) .pipe(rename(conf.bundle)) .pipe(gulp.dest(conf.dest)) .on('end', function() { cb() }) }, function(err) { cb(err) } ) })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• function bundle（）{...} -browserifyの自己記述ラッパー。 ブラウザを使用する人は、ブラウザ化自体がストリームの操作方法を知っていることを長い間知っているため、gulp-browserifyパッケージは長い間使用されていません。
• [parseArgs] -コマンドライン引数を解析するためのタスクの依存関係で指定します。 したがって、argv変数にはすでに有効な設定が含まれていると確信しています。
• async.each、cb（） -引数で指定されたアプリケーションの列挙。 コールバックに問題やトラブルが発生するのはなぜですか？ 実際には、アセンブリプロシージャ自体（gulp.src（）。Pipe（）...）は非同期であり、チェーン全体が実行される前にタスクを完了することができます。これにより、次のようになります。依存タスクは実行を早く開始します。 3つの解決策があります-タスクからのコールバック、ストリームタスクからの戻り-gulp.src（）...を返し、promiseを返します。 ストリームがいくつかあるため、ここにストリームを返すことはできません。そのため、コールバックに決めました。
• .pipe（gulp.dest（conf.dest）） -収集されたパッケージはjs application configで指定された静的フォルダーにコピーされるため、展開時にcollectstaticは追加のジェスチャーなしでジョブを実行します。

ファイルの変更時の再コンパイル

jsアプリケーションファイルの変更を監視するタスク：

 gulp.task('watch', ['build'], function() { var targets = [] _.each(argv.apps, function(app) { var conf = config.apps[app] if (!conf) return if (conf.watch) { if (_.isArray(conf.watch)) { targets = _.union(targets, conf.watch) } else { targets.push(conf.watch) } } }) targets = _.uniq(targets) // start watching files gulp.watch(targets, ['build']) })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• ['build'] -依存関係でビルドタスクを指定します。 まず、監視の開始前にアプリケーションを再構築します。次に、ビルドビルドの前にコマンドライン引数が解析されることを知っています。
• _.each（argv.apps、...） -引数で指定されたアプリケーションを反復処理し、構成で設定を確認し、ターゲットを収集して変更を観察します。
• gulp.watch（targets、['build']） -監視を開始し、変更時にビルドタスクが実行されます。 欠点が1つあります。複数のアプリケーションの監視を実行すると、変更があるとすべてが再構築されますが、実際には、複数のアプリケーションを同時に監視する必要はない（実際にはない）ので、気にしません。

時計が完成した後に縮小して再組み立てする-2番目のトリック

開発プロセスは次のようになります： django開発サーバーを起動し、 gulpウォッチを起動し、フロントエンドアプリケーションを作成/デバッグします。 したがって、開発プロセス自体により、実際にアセンブルされたアプリケーションが変更とともに静的フォルダーにすぐに表示されるようになり、展開中に追加の手順が不要になります。 しかし、問題は、開発が通常--devパラメーター（縮小なし）で実行され、現在、公園で数回、サイズが2メガバイトの縮小されていないパッケージの生産をコミットしていることで、何らかのリマインダーを考え出す必要があると思いました。より良い自動化。



そのため、監視タスクに次のコードが登場しました。

  // handle Ctrl+C and build a minified version on exit process.on('SIGINT', function() { if (!argv.dev) process.exit() argv.dev = false console.log() gutil.log(gutil.colors.yellow('Building a minified version...')) gulp.stop() gulp.start('build', function() { process.exit() }) })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• CTRL + Cをキャッチします。
• 時計が縮小されて起動された場合、単純にプロセスを終了します。
• argv.dev = false-次のビルドで実動用のパッケージを収集できるように、縮小禁止をキャンセルします。
• gulp.stop（） -現在のすべてのタスクを完了します。
• gulp.start（ 'build'、function（）{...}） - ビルドタスクを呼び出し、完了後に終了します。 ここで非常に重要なのは、前述のビルドタスクでビルド後のコールバックが正しく呼び出されたことです。さもないと、パッケージが静的フォルダーにコピーされてプロセスが終了する前にタスクが終了します。 startメソッドは、実際にはそのメソッドではないため、gulpのドキュメントには含まれていません。Orchestratorから継承されました。

結果は次のとおりです。gulpwatch --app appname --devを実行し、アプリケーションをデバッグし、CTRL + Cを押して監視を停止すると、 gulpはパッケージの縮小バージョンをすぐに収集します。 私たちは生産における労働の結果を静かにコミットし、楽しんでいます。

まとめ

デプロイメントプロセス中に変更を加えることなく、実稼働環境に新たに依存することなく、jsアプリケーションを構築するシステムを手に入れました。 コードをモジュールに分割し、出力で1つのコンパクトファイルを取得できました。 ここで、js-linter、テストなどを追加できます。



同様に、たとえばスタイルをいくつかのスタイラスに簡単に転送し、それらを縮小することもできますが、人間の理由を考慮して、まだそうしていません。



読んでくださった皆さん、ご清聴ありがとうございました。



サンプルアプリケーションで完全にGulpfile 。