webpack複数ページ応用アーキテクチャシリーズ(七):開発環境、生産環境が馬鹿で分かりませんか?

8279 ワード

javascript webpack

この文章は最初に
Aray_Huangの技術ブログ―― 、著作者の同意なしに転載しないでください.
原文の住所:https://segmentfault.com/a/1190000006952432このシリーズの文章に興味があるなら、ここに注目してください.https://segmentfault.com/blog/array_huang前言
開発環境と生産環境の分離の原因は以下の通りです.

開発時、大量のdebugまたはテストコードが発生することは避けられません.これらのコードは生産環境に現れるべきではありません.

ページをサーバーに配置する時、極致の技術指標を追求するために、コードに対して様々な最適化を行います.例えば、混淆、圧縮などの手段はコード自体の可読性を徹底的に破壊し、debugなどの仕事に不利です.

データソースの差異化、例えば、ローカル開発時にはローカルmockからのデータを読み取ることが多いが、正式オンラインになってから読むのは当然APIからのデータである.

無理に開発環境と生産環境で同じコードを使うと、必ず重い代価を払います.
開発環境と生産環境をどのように分離するかを紹介します.一つはどのように異なる方法でコンパイルしますか?つまり、開発環境と生産環境のwebpack配置ファイルをそれぞれ形成します.第二に、ビジネスコードの中で、環境によってどのように違った処理が行われますか?
開発環境と生産環境のwebpack配置ファイルをどのように分離しますか?
同時に一つの完全な開発環境プロファイルと一つの完全な生産環境プロファイルを並べて比較すれば、次の三つの状況が現れます.

開発環境によっては、必ずしも生産環境があるとは限りません.例えば開発時にsourcemapを生成してdebugを助けたり、熱更新時に使用されるHotModuleReplacementPlugin.

生産環境によっては、開発環境が必ずしもあるとは限らない.例えば、jsを混同するためのUglifyJsPlugin.

開発環境と生産環境はすべて持っている構成ですが、詳細にはoutput.publicPath、例えばcss-loaderのminimizeとautoprefixerのパラメータがあります.

更に重要なのは、実際に開発環境と生産環境の配置文書のほとんどが一致しています.この一致した部分に対して、私達は断固として冗長性を除去します.そうでないと、その後の維持は面倒なだけでなく、間違いやすいです.
どうしますか
答えは簡単です.webpackの設定ファイルをNつの小さいmoduleに分割します.もとは私達は1つの完備している配置のファイルで、何百行もあって、初めから最後まですべて頭が大きくなったことを見て、更に分離しないことを言う必要はありません.分離の結果を見てみます.

├─webpack.dev.config.js #      webpack    （     ，      ）
├─webpack.config.js #      webpack    （     ，      ）
├─webpack-config #       webpack    
  ├─entry.config.js # webpack        ，           
  ├─module.config.js
  ├─output.config.js
  ├─plugins.dev.config.js #             ，            webpack.dev.config.js   
  ├─plugins.product.config.js #             ，            webpack.config.js   
  ├─resolve.config.js
  │  
  ├─base #          
  │   ├─dir-vars.config.js
  │   ├─page-entries.config.js
  │      
  ├─inherit #                 ，    
  │   ├─plugins.config.js
  │      
  └─vendor #   webpack             
      ├─eslint.config.js
      ├─postcss.config.js

ファイルディレクトリの構造を見ました.最後の配置ファイルを整理するにはどうすればいいですか?

/*     webpack    webpack.dev.config.js */
module.exports = {
  entry: require('./webpack-config/entry.config.js'),

  output: require('./webpack-config/output.config.js'),

  module: require('./webpack-config/module.config.js'),

  resolve: require('./webpack-config/resolve.config.js'),

  plugins: require('./webpack-config/plugins.dev.config.js'),

  eslint: require('./webpack-config/vendor/eslint.config.js'),

  postcss: require('./webpack-config/vendor/postcss.config.js'),
};

これで、開発/生産環境設定ファイルの同じ部分と異なる部分を簡単に処理できます.
開発/生産環境の配置ファイルはどうやって呼び出しますか?
「web pack複数ページアプリケーションアーキテクチャシリーズ(二):web pack構成の常用部分はどれですか?」で述べましたが、コンソールでwebpackコマンドを呼び出してパッケージを起動する時に、--configパラメータを追加してwebpack設定ファイルのパスを指定してもいいですか?私たちはnpm scriptsに合わせて使用できます.package.jsonで定義します.

  "scripts": {
    "build": "node build-script.js && webpack --progress --colors",
    "dev": "node build-script.js && webpack --progress --colors --config ./webpack.dev.config.js",
    "watch": "webpack --progress --colors --watch --config ./webpack.dev.config.js"
  },

こうすれば、私たちが開発したときにはnpm run devまたはnpm run watchを使用して、オンラインで荷造りするときにはnpm run buildを実行することができます.
業務コードはどうやって生産/開発環境を判断しますか?
ビジネスコードで生産/開発環境を判断するのは簡単です.変数一つでいいです.

if (IS_PRODUCTION) {
    //           
} else {
    //           
}

これは、この変数IS_PRODUCTIONがどうやって来たかが鍵となる.
私はまだ開発と生産環境を分離していません.開発時に業務コードで使用される配置ファイルの中でこの変数をfalseに設定して、最後にオンラインを包装する時に手動でtrueに変更する方法を使っています.このような方法は一時期使ったことがあります.とても煩わしいです.そしてよくオンラインしてみたら、私はどうやってajaxに行ったらいいですか?
どうしますか
多くの文章を参考にしましたが、まず私が採用していない方法を大雑把に説明します.

は、EnvironmentPluginを用いてprocess.envを導入することによって、業務コードの中でprocess.env.NODE_ENVによって判断することができる.

は、異なる環境において異なるプロファイル(トラヒックコード用)をロードするようにProvidePluginで制御する.

私が使っているのはどんな方法ですか?最後に選んだのはDefinePluginです.
公式例を挙げると、その大体の使い方はこうです.

new webpack.DefinePlugin({
    PRODUCTION: JSON.stringify(true),
    VERSION: JSON.stringify("5fa3b9"),
    BROWSER_SUPPORTS_HTML5: true,
    TWO: "1+1",
    "typeof window": JSON.stringify("object")
})

DefinePluginは、その役割はwebpackプロファイルにおいてコンパイルされたコードコンテキスト環境のために大域変数が設定されていると誤解されるかもしれないが、そうではない.その真のメカニズムは、DefinePluginのパラメータがobjectである場合、いくつかのkey-valueペアがあります.webpackコンパイルの場合、トラフィックコードには定義がなく、変数名はkeyと同じ変数(直接コードを読むとグローバル変数のようです)に置き換えられます.例えば上記の公式例では、valueはPRODUCTIONに置き換えられる.trueはVERSIONに置き換えられます.'5fa3b9'もBROWSER_SUPPORTS_HTML5に置き換えられる.trueは、TWOに置き換えられる(したがって、数学的表現に相当する).1+1はtypeof windowに置き換えられた.
もう一つの例を挙げてください.たとえばコードにはこう書いてあります.

if (!PRODUCTION)
    console.log('Debug info')
if (PRODUCTION)
    console.log('Production log')

コンパイルで生成されたコードの中ではこうなります.

if (!true)
    console.log('Debug info')
if (true)
    console.log('Production log')

'object'を使ったら、こうなります.

console.log('Production log')

このようにすれば、2つの環境のプロファイルにUglifyJsPluginでDefinePluginの値をそれぞれ定義しておけば、ビジネスコードで判断できる.

  /* global IS_PRODUCTION:true */
  if (!IS_PRODUCTION) {
    console.log('       Log，                ');
  }

注意したいのは、webpackにESLINEが統合されている場合、ESLintは、定義されていない変数(ESLINEがグローバル変数の使用を要求する場合はIS_PRODUCTIONと書く)を検出するので、window.xxxxxの注釈文(global)IS_が必要です.PRODUCTIONはグローバル変数です.
サンプルコード
皆さんはこのシリーズの文章を見て、私のGithub上の足場プロジェクトに合わせて食べたほうがいいですよ(笑):アラ-Huing/webpack-seed(/* global IS_PRODUCTION:true */).
シリーズの記事カタログを添付します(同期更新)

webpack複数ページアプリケーションアーキテクチャシリーズ(一):一歩ずつアーキテクチャの痛みを解決する:https://github.com/Array-Huang/webpack-seed

webpack複数ページアプリケーションアーキテクチャシリーズ(二):webpack構成の常用部分は何ですか?https://segmentfault.com/a/1190000006843916

webpack複数ページアプリケーションアーキテクチャシリーズ(三):共通コードをどうやって梱包すれば重複を回避できますか?https://segmentfault.com/a/1190000006863968

webpack複数ページアプリケーションアーキテクチャシリーズ(四):旧式jQueryプラグインはまだなくしてはいけませんが、どう対応していますか?https://segmentfault.com/a/1190000006871991

webpack複数ページアプリケーションアーキテクチャシリーズ(五):webpackはless/cssまで包装できると聞きました.https://segmentfault.com/a/1190000006887523

webpack複数ページアプリケーションアーキテクチャシリーズ(六):webpackは写真とフォントも包装できると聞きました.https://segmentfault.com/a/1190000006897458

webpack多ページ応用アーキテクチャシリーズ(七):開発環境、生産環境が馬鹿で分かりません.https://segmentfault.com/a/1190000006907701

webpackマルチページアプリケーションアーキテクチャシリーズ(8):コーチはES 6を書きます.webpackはどうやってBabelを統合しますか?https://segmentfault.com/a/1190000006952432

webpack多ページ応用アーキテクチャシリーズ(9):いつも意地悪な人が余を害したいです.ESLintはごみコードをブロックします.https://segmentfault.com/a/1190000006992218

webpack複数ページアプリケーションアーキテクチャシリーズ(10):どのようにカスタマイズされたbootstrapを作成しますか?https://segmentfault.com/a/1190000007030775

webpack複数ページアプリケーションアーキテクチャシリーズ(11):プリパックDll、webpack音速コンパイルを実現する:https://segmentfault.com/a/1190000007043716

webpack複数ページアプリケーションアーキテクチャシリーズ(12):webpackを利用してHTML普通ページ＆ページテンプレートを生成する:https://segmentfault.com/a/1190000007104372

webpack複数ページアプリケーションアーキテクチャシリーズ(13):簡単なテンプレートレイアウトシステムを構築する:https://segmentfault.com/a/1190000007126268

webpack複数ページアプリケーションアーキテクチャシリーズ(14):Noコピー貼り付け!多項目共用インフラ

webpack複数ページアプリケーションアーキテクチャシリーズ(15):フロントエンドがバックエンドレンダリング開発モードにおいて、サンドイッチ生存

webpack複数ページアプリケーションアーキテクチャシリーズ(十六):ブラウザキャッシュを善用し、行くならば、

を残します.
この文章は最初に
Aray_Huangの技術ブログ――https://segmentfault.com/a/1190000007159115、著作者の同意なしに転載しないでください.
原文の住所: このシリーズの文章に興味があるなら、ここに注目してください.https://segmentfault.com/a/1190000006952432

JavaScript特定のテーマの学undersscoreは配列の中で指定の要素を探します.