はじめに

この記事はこれの続きです。

この記事は補足として使用していただけるといいかなと思います。
随時章を追加していきます。
間違っている部分があれば優しく教えてください。

章ごとのまとめ

chapter3

1. Express

Expressはnodeのweb applicationフレームワーク。
このチュートリアルでは、コードを

src/client/ ... クライアントサイドの処理を書く。
src/shared/　... clientとserver側で共通に使いたい処理を書く。
src/server/ ... サーバー側の処理を書く。

に分けていた。

yarn add express compression

でexpressとcompressionを入れて終わり。

Expressのコード補足

WEBPORTは後でherokuにあげるときのために、process.env.PORTの値を受け取れるようにしている。
2種類の静的なファイルを格納するディレクトリを扱う。一つはgenerateされたファイルを格納するdist。もう一つは宣言的なファイルを格納するpublic。
app.use(STATIC_PATH, express.static('dist'))らへんが分からなければこちら

2. nodemon

nodemonはファイルが変更された際、nodeサーバーを自動的にリスタートしてくれるユーティリティ。

yarn add --dev nodemon

package.json

  "start": "yarn dev:start",
  "dev:start": "nodemon --ignore lib --exec babel-node src/server",

こうすれば、lib以外のファイルを変更した時にサーバーを毎回自動的にrestartしてくれる。

3. PM2

PM2はnodeのプロセスのモニタリングや管理ができる。

今まではbabel-nodeを使ってサーバーを立ち上げていたけど、productionでは重すぎるので、babelを使用してビルドしたい。新しいビルドの際に毎回以前ビルドされたファイルを消しておくのがgood practiceなので、rimrafを使用する。rimrafはファイルの削除をcross platformで行える。

yarn add --dev rimraf

productionでのビルドのタスクをscriptとして定義する。

package.json

  ...
  "prod:build": "rimraf lib && babel src -d lib --ignore .test.js",
  ...

次に、pm2を使用するため、pm2とcross-envを入れる。
cross-envは、osごとの環境変数設定のシンタックスの違いを吸収してくれる。

yarn add --dev pm2 cross-env

package.json

  ...
  "prod:start": "cross-env NODE_ENV=production pm2 start lib/server && pm2 logs",
  "prod:stop": "pm2 delete server",
  ...

これで

yarn prod:build
yarn prod:start

すればproduction用サーバが立ち上がる。また、

ctrl + c すれば pm2 logs コマンドはkillされるが、サーバー自体を落としたい場合は
yarn prod:stop すれば良い。

あとは、プッシュの前にビルドが正常にできるか確認するため、

package.json

  ...
  "prepush": "yarn test && yarn prod:build",
  ...

としておく。

chapter4

1. Webpack

Webpackはモジュールバンドラー。javascriptファイルを(大抵)1つのファイルにまとめるので、クライアントはそのファイルを読み込めばいいようになる。

yarn add --dev webpack webpack-dev-server babel-core babel-loader

bable-loaderは今まで扱ったbabelと同じようにコードをトランスパイルするプラグインだが、今回はブラウザで動作させるために使っている。
babel-coreはbabel-loaderとpeer-dependencyなので、一緒に入れている。

Webpack　コード補足

Webpackの設定ファイルにのbabelの変換を適応するために、.babel.jsという拡張子をつける。
entryは自分のアプリのstarting point
output.filenameは生成されるバンドルファイルの名前
output.pathは生成されるバンドルファイルが格納されるフォルダ
output.publicPathは生成されるバンドルファイルのフォルダを指し示すURL
moduel.rulesはWebpackがどのファイルを取り扱うかの指定
resolve　は指定した拡張子のファイルをimportする時に使用される
クライアントサイドで新しいESのフィーチャーを使用したければyarn add babel-polyfillして、ファイルで　import babel-polyfill　と記述すれば良い。
windowやdocumentなど、ブラウザに関するキーワードを使用する場合、ESlintに引っかからないようにするために

.eslintrc.json

  "env": {
    "browser":true
  }

とする。

package.json

"scripts": {
  "dev:wds": "webpack-dev-server --progress",
  "prod:build": "rimraf lib dist && babel src -d lib --ignore .test.js && cross-env NODE_ENV=production webpack -p --progress",
  "lint": "eslint src webpack.config.babel.js --ext .js,.jsx",
}

スクリプトを上記のように変更すれば、
開発環境では

yarn start

別ターミナルで

yarn dev:wds

とすれば、正常にアクセスできるようになる。ブラウザ開発ツールのsource内でwebpack://./srcをみて、ES6で書かれた元のファイルが全て確認できるなら、sourcemapがきちんと動いていることを確かめれる。

また、

yarn prod:build
yarn prod:start

して、　http://localhost:8000/static/js/bundle.js にアクセスすれば、Webpackによってビルドされたクライアントサイドのコードを見ることができる。

2. React

Reactはfacebook製のユーザーインターフェースをビルドできるライブラリ。

yarn add react react-dom

reactを書く際にも、ES6のシンタックスチェックと、型チェックをしたいので、

yarn add --dev babel-preset-react babel-plugin-flow-react-proptypes

.babelrc

{
  "presets": [
    "react"
  ],
  "plugins": [
    "flow-react-proptypes"
  ]
}

とする。

3. Hot Module Replacement

Hot Module ReplacementはWebpackの機能の一つで、手動でリロードしなくとも、moduleに変更があった場合にその変更をブラウザに反映してくれる。

今回はreact用にreact-hot-loaderを入れる。

yarn add react-hot-loader@next

webpack.config.babel.js

import webpack from 'webpack'
// [...]
entry: [
  'react-hot-loader/patch',
  './src/client',
],
// [...]
devServer: {
  port: WDS_PORT,
  hot: true,
  headers: {
    'Access-Control-Allow-Origin': '*',
  },
},
plugins: [
  new webpack.optimize.OccurrenceOrderPlugin(),
  new webpack.HotModuleReplacementPlugin(),
  new webpack.NamedModulesPlugin(),
  new webpack.NoEmitOnErrorsPlugin(),
],

WebpackのHMRの設定に関してはここに記述してある。

pluginがいくつも出てきたが、

optimize.OccurrenceOrderPlugin...リンク先の説明を参照してください。
HotModuleReplacementPlugin...HMRを有効にするために必要なプラグイン
NamedModulesPlugin...HMRを使用している時、moduleの相対パスを表示してくれる(HMRを入れる時にこいつも入れるよう推奨されている)
NoEmitOnErrorsPlugin...コンパイル中にエラーがでたemittin_phaseをスキップする。これでerrosを含んだアッセットがemitされないことを保証できる。？(ここはあまりよく分かっていないです。誰かわかる方がいれば)

devServer.headersのcross-origin設定に関しては、こちら。

実際にHMRに必要なプラグインはHotModuleReplacementPluginとNamedModulesPlugin(推奨)のみ。