2016年版を書いてからもう1年もたってさらに古くなってきたので、今の環境に合わせてバージョンアップ
僕なりのフロントエンド開発環境2016年版 - Qiita
僕なりのフロントエンド開発環境2016年版v2 - Qiita
https://github.com/koh110/minjsapp

2016年版からのバージョンアップ点

webpackをv2に
vendor.jsの切り出しかたをgulpからwebpackに
gulpfileにあったwebpackのconfigをwebpack.config.jsに切り出し
環境変数にパスを切り出し

webpackをv2に

webpackのv2がついにリリースされたので移行。
古い環境はどんどんとおいていかれるのでなるべく早めにやったほうが最終的な移行コストは低くなると思います。

vendor.jsの切り出し方をgulpからwebpackに

今までは依存するライブラリ（jQueryなど）はgulp-concatでファイル連結していました。
webpackで依存関係を保ちながらvendor.jsだけ分割できるというのは知っていましたが、当時webpackが本当に本流になるかは読めなかったので、必要最小限のタスクに留めようと思いgulp-concatにしていました。
逆に1年経った今ではgulp v4リリースの兆しも見えなくなり、こっちの依存を最小限にするべきだと判断しました。

webpack内に内包されているCommonsChunkPluginというのを使うと勝手にお互いのファイルの依存関係を判断してファイルを出力してくれます。
下記の例でいくとvendor.jsにjqueryの内容を出力して、app.jsはvendor.jsに吐き出されたjqueryを利用するようになります。

webpack.config.js

  entry: {
    app: `${__dirname}/app.js`,
    vendor: `${__dirname}/vendor.js`
  },
  plugins: [
    new webpack.optimize.CommonsChunkPlugin({
      name: ['app', 'vendor']
    })
  ]

vendor.js

require('jquery/dist/jquery.min.js');

app.js

const $ = require('jquery/dist/jquery.min.js');

const txt = $('.hello').text();
console.log(txt);

gulpfileにあったwebpackのconfigをwebpack.config.jsに切り出し

webpackが出始めた頃はまだwebpackがなくなるリスクがあると思っていました。（Browserifyが台頭する可能性など）初めてみた人がwebpackを使っていることを意識しなくてすむような形にしようと考えました。
また、これは今も完全には解決してないですがディレクトリ直下に謎のファイルが増えすぎるのは好きではないです。
今はもう十分一般化されたと思うので逆に切り出した方が理解しやすくなるという判断で今回は切り出しました。

環境変数にパスを切り出し

gulpfileの中にwebpackのconfigを入れるメリットは、成果物を吐き出すパスを入れた変数などを共有できるとかもありました。
しかし、今回はwebpack.config.jsを切り出すと決めたので、それぞれにnpm scriptで呼び出すときに環境変数としてパスを渡す仕様にしました。

package.json

  "scripts": {
    "start": "SRC_PATH=./app DIST_PATH=./dist gulp",
    "build": "SRC_PATH=./app DIST_PATH=./dist gulp build",
    "lint": "gulp lint"
  },

gulpfile.js

const path = require('path');
const SRC_PATH = path.resolve(process.env.SRC_PATH);
const DIST_PATH = path.resolve(process.env.DIST_PATH);

gulp.task('html', () => {
  return gulp.src(`${SRC_PATH}/index.html`)
    .pipe(gulp.dest(DIST_PATH));
});

webpack.config.js

const path = require('path');
const DIST_PATH = path.resolve(process.env.DIST_PATH);

module.exports = {
  output: {
    path: DIST_PATH
  },
...
};

webpackを使おうがgulpを使おうが基本的にnpm scriptsにまとめるというのはやったほうがいいです。
今回のようにビルド方法のコマンドの内容が変わった時にも同じコマンドのまま修正ができるし、npm scriptsに書いたコマンドはnode_modulesにインストールしたものを利用してくれるので、webpackのバージョンがv1 -> v2に上がっても自分のグローバルにインストールしたものとかぶらずにすみます。

まとめ

今回はほとんどwebpackのバージョンアップ対応だけですみました。
少しフロントエンドのタスクの環境も落ち着いてきた気がします。
年々gulpはただnodeのmoduleを呼び出すだけになり依存するものを減らしていくのが特徴になりつつあります。
全部npm scriptsにまとめりゃgulpいらないじゃんという声もありますが、タスク同士の依存関係とかを書くのにはまだgulpが楽かな、というのとnpm scriptsが散乱しがちなのでそれをgulpfileにまとめるメリットはあると僕は思います。
疎結合にするというのは健全な道だと思いますが、逆に複雑度が増していってとっつきづらくなっているのはなんとかならんもんかなぁと思いました。

僕なりのフロントエンド開発環境2017年版

2016年版からのバージョンアップ点

webpackをv2に

vendor.jsの切り出し方をgulpからwebpackに

gulpfileにあったwebpackのconfigをwebpack.config.jsに切り出し

環境変数にパスを切り出し

まとめ