「Webpack」の記事 - Crieit

【JS/Webpack】ビルドしたフォルダの不要ファイルを削除する

2022-08-24T23:45:46+09:00

こんにちは、しきゆらです。今回は、Webpackでビルドしたものが出力されるフォルダにできる不要ファイルを削除する方法を知ったのでメモしておきます。

WebpackでJSのコードをビルドしていると、結構な頻度で不要なファイルができたりします。例えば、デバッグ用に生成したソースマップファイルがそのまま残っていたり、過去に設定を変えてあるところから出力しなくなったファイルが残っていたり等、ビルド先のdistフォルダの中はごちゃごちゃしがちです。これを何とかしたいなぁ、と思って調べたら簡単に解決できました。

Webpackでこういうことできないかなぁと調べると大抵プラグインが出てきて追加しないといけないことが多く、今回もそのパターンでよくわからないものを追加しないといけないのかなぁ・・・と思っていたのですが、どうも標準機能として用意されているようでした。ということで結論。

結論: outputの中に[clean: true]を追加すればよい

ドキュメントを読むことは大事ですね。しっかり記載がありました。

https://webpack.js.org/guides/output-management/#cleaning-up-the-dist-folder

こちらによると、ビルドしたものを置くdistフォルダの中身をビルドのたびにきれいにしたい場合はoutput.cleanオプションを使え、とあります。ただし、この方法が使えるのはWebpack5以降のみなので注意してください。

// webpack.config.jsの一部分
~~~~~~
output: {
   filename: "output.js",
   path: path.resolve(__dirname, "dist"),
   clean: true // この1行を追加すればよい
}

はい、たったこれだけ。１行追加するだけで、ビルドのたびにdistフォルダの中身をきれいにしてくれるので、過去にビルドした残骸が残ることはなくなりました。

また、こちらのページには細かい設定方法もありました。

https://v4.webpack.js.org/guides/output-management/#cleaning-up-the-dist-folder

そして、前述の通りこの方法が使えるのはWebpack5以降のみとのことでした。Webpack4などを使っている方は、プラグインでの対応となるようです。

Webpack4を使っている方: clean-webpack-pluginを使う

https://v4.webpack.js.org/guides/output-management/#cleaning-up-the-dist-folder

Webpack4版のドキュメントを見ると、同様の項目ですが対応方法が異なっていました。「clean-webpack-plugin」というプラグインを使えば削除できるので、導入・設定しましょうとのことでした。以下にドキュメントにあったサンプルを載せておきます。

# プラグインのインストール
npm install --save-dev clean-webpack-plugin

webpack.config.jsはこんな感じ。

// webpack.config.js
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
// プラグインを読み込む
const { CleanWebpackPlugin } = require('clean-webpack-plugin');

module.exports = {
  entry: {
    app: './src/index.js',
    print: './src/print.js',
  },
  plugins: [
    new CleanWebpackPlugin(), // この行を追加する
    new HtmlWebpackPlugin({
      title: 'Output Management',
    }),
  ],
  output: {
    filename: '[name].bundle.js',
    path: path.resolve(__dirname, 'dist'),
  },
};

これにより、output.pathで指定したフォルダにある不要ファイルを削除したうえでビルドしてくれるとのことでした。さらに、Webpack5では細かい設定ができましたが、clean-webpack-pluginでも似たような設定はできそうです。

https://www.npmjs.com/package/clean-webpack-plugin

まとめ

今回は、Webpackで過去にビルドした残骸をきれいに削除する方法をまとめました。不必要なプラグインを導入せずに、たった１行の設定追加だけでやりたかったことが実現できてとてもハッピーです。

そして、Webpack5ではデフォルトでこの機能が入っていることを知りませんでした。過去に調べたときはプラグイン対応だったよなぁと思いつつ調べると、やはりプラグインを導入しろ、という記事が多く出てきました。とりあえずググるのは大事ですが、ドキュメントをさっくりと眺めておく、というのも必要ですね。

Webpack でバンドルしたライブラリを他の JavaScript から参照したい

2021-03-01T23:48:35+09:00

大体の JavaScript は Webpack でバンドルするのですが、一部対象外の JavaScript を用意したときに Webpack でバンドルしたライブラリを外部から参照できなかったのでメモ。

検証

この状態で Webpack でバンドルすると、 dist/js/external.js からは dist/js/app.js にバンドルされた jQuery が参照できません。

そのため、以下のようなエラーが表示されてしまいます。

Uncaught ReferenceError: $ is not defined

対処

そこで、 expose-loader を加えた ( yarn add -D expose-loader ) 上で webpack.config.js を以下のように書き換えます。

const webpackTerser = require('terser-webpack-plugin');
const path          = require('path');
const glob          = require('glob');

const entry = () => {
    const entries = glob
        .sync(
            '**/*.js',
            {
                cwd: './src/js'
            }
        )
        .map(function (key) {
            return [key, path.resolve('./src/js', key)];
        });
    return Object.fromEntries(entries)
};
const configs = {
    mode: 'development',
    entry: entry(),
    output: {
        filename: '[name]',
        path: path.join(path.join(__dirname, 'dist'), 'js')
    },
    module: { // ここから
        rules: [
            {
                test: require.resolve("jquery"),
                loader: "expose-loader",
                options: {
                    exposes: ["$", "jQuery"],
                }
            }
        ]
    }, // ここを追記
    optimization: {
        minimizer: [
            new webpackTerser({
                extractComments: 'some',
                terserOptions: {
                    compress: {
                        drop_console: false,
                    },
                },
            }),
        ],
    },
    devtool: 'inline-source-map'
};

module.exports = configs;

これでもう一度ビルド。

今度はエラーがなく、出力処理が正常にできたことが確認できました。OKです。

webpack --watch で差分ビルドの完了時に任意のコマンドを実行する

2021-01-27T04:15:28+09:00

「任意のコマンドを実行」としたけど、要するに完了にフックして通知がしたい。

（※ 2019-01-29 に書いた記事のクロス投稿です）

単純な watch の実行:

$(npm bin)/webpack --watch --config webpack.config.js

これだけだと（差分）ビルド完了の検出がやりにくそうなので、 --info-verbosity verbose を追加する。

Watch and WatchOptions > info-verbosity

Setting info-verbosity to verbose will also message to console at the beginning and the end of incremental build. info-verbosity is set to info by default.

$(npm bin)/webpack --watch --config webpack.config.js \
  --info-verbosity verbose

開始時と完了時にこういうメッセージが出力される:

Compilation  starting…
Compilation  finished

あとは適当なラッパーを書いて、完了メッセージを検出してコマンドを実行すればOK。 Ubuntu だと notify-send コマンドで通知できる。 Webpack の設定でできるか調べるよりこっちの方が速かった……。まあでもこの方法なら webpack 以外でも使いまわせるし、いいよね、ということにしておく。

#!/usr/bin/env ruby

require "pty"

npm_bin = `npm bin`.chomp

watch_cmd = [
  "#{npm_bin}/webpack",
  "--watch",
  "--config webpack.config.js",
  "--color=false",
  "--info-verbosity verbose"
].join(" ")

PTY.spawn(watch_cmd) do |i, o|
  loop do
    line = i.gets
    print line
    if line.chomp == "Compilation  finished"
      timestamp = Time.now.strftime("%F %T")
      system "notify-send 'Compilation finished #{timestamp}'"
    end
  end
end

試しにやってはみたものの、今手元にあるものは規模が小さくてビルドがすぐ終わるので便利になったかよく分からない（やる前に気付こう）。

$(npm bin)/webpack --version
4.29.0

Webpack (webpack-stream) でエントリーポイントを動的に変更する

2021-01-27T00:00:53+09:00

Scss に続いて JS でも動的に読み込むファイルを切り替えたいと考えました。

Webpack の clean-webpack-plugin のメモ

2021-01-21T00:22:56+09:00

よんどころなき事情により Webpack で clean-webpack-plugin を使おうとしたのですが、過去の記事を見ていたら嵌まったのでメモしておきます。

経緯

処理中のフラグによって .js ファイルを複数出力(数はフラグにより増減)しようとしたのですが、減らすときは当然 output 先 (ここでは dist/js )は前の出力結果が残ってしまっているので、余計なゴミとして残ってしまうことに気付きました。

そこで Webpack のビルド直前に output 先をクリーニングしようと考え、検索すると clean-webpack-plugin がヒットしたので、これを試そうとしました。

なお、パッケージの指定は以下の通りです。

    "devDependencies": {
        "webpack": "^5.15.0",
        "webpack-stream": "^6.1.1",
        "terser-webpack-plugin": "^5.1.1",
        "clean-webpack-plugin": "^3.0.0"
    },
    "resolutions": {
        "webpack": "^5.15.0"
    },

Gulp から webpack-stream 経由で Webpack を使用、という状況です。

現象

clean-webpack-plugin の使い方の記事を見ると、 webpack.config.js に以下のように書くケースが散見されました。

const webpackTerser          = require('terser-webpack-plugin');
const { CleanWebpackPlugin } = require('clean-webpack-plugin'); // require
const path                   = require('path');
const glob                   = require('glob');

const entry = () => {
    const entries = glob
        .sync(
            '**/*.js',
            {
                cwd: 'src/js',
                ignore: [
                    '**/_*.js'
                ]
            }
        )
        .map(function (key) {
            return [key, path.resolve('src/js', key)];
        });
    return Object.fromEntries(entries);
};
const configs = {
    mode: 'development',
    entry: entry(),
    output: {
        filename: '[name]',
    },
    devtool: 'inline-source-map',
    plugins: [
        // plugin
        new CleanWebpackPlugin([
            'dist/js' // cleanup path
        ]),
    ],
    optimization: {
            minimizer: [
            new webpackTerser({
                extractComments: 'some',
                terserOptions: {
                    compress: {
                        drop_console: false,
                    },
                },
            }),
        ],
    },
};

module.exports = configs;

今回引っかかったのは CleanWebpackPlugin インスタンスへの引数で「クリーニングしたいディレクトリのパスの配列」を指定する部分。

Error: clean-webpack-plugin only accepts an options object. See:
            https://github.com/johnagan/clean-webpack-plugin#options-and-defaults-optiona

clean-webpack-plugin の引数はオブジェクトの形式ですって？

散見される記事は配列でした。

上記エラー文の通り、 Github を参照すると……確かにオブジェクトの形式で指定されています。

これ以上は突っ込んでいませんが、どうやらどこかのバージョン (今回インストールした clean-webpack-plugin は 3.0.0 だったので、2系と3系で乖離があるのかもしれません) で仕様が変わったのかもしれません。

これを受けて以下のように修正。

const webpackTerser = require('terser-webpack-plugin');
const { CleanWebpackPlugin } = require('clean-webpack-plugin'); // require
const path          = require('path');
const glob          = require('glob');

const entry = () => {
    const entries = glob
        .sync(
            '**/*.js',
            {
                cwd: 'src/js',
                ignore: [
                    '**/_*.js'
                ]
            }
        )
        .map(function (key) {
            return [key, path.resolve('src/js', key)];
        });
    return Object.fromEntries(entries);
};
const configs = {
    mode: 'development',
    entry: entry(),
    output: {
        filename: '[name]',
    },
    devtool: 'inline-source-map',
    plugins: [
        new CleanWebpackPlugin({
            cleanOnceBeforeBuildPatterns: [
                'dist/js/**/*.js' // cleanOnceBeforeBuildPatterns キーの中に配列指定。また、ディレクトリパスの指定ではなく、 glob での指定
            ],
        }),
    ],
    optimization: {
            minimizer: [
            new webpackTerser({
                extractComments: 'some',
                terserOptions: {
                    compress: {
                        drop_console: false,
                    },
                },
            }),
        ],
    },
};

module.exports = configs;

変更点は以下の2つ。

指定そのものを cleanOnceBeforeBuildPatterns キーに対する値として配列を記述するようにしたこと
ディレクトリパスではなく glob 指定ということ (拡張子指定が不要な場合は dist/js/**/* というような形)

これで意図した挙動になりました。

余談

最初とりあえず試すだけ試そうとして

    plugins: [
        new CleanWebpackPlugin(),
    ],

途中試験のため cwd も抜いていたせいで、引数なしで CleanWebpackPlugin インスタンスを起こしたところ、プロジェクトルートからファイルを削除しようとして焦りました (デフォルトが dry: false(テストなし), verbose: false(削除するファイルをコンソールに出力しない), cleanOnceBeforeBuildPatterns: ['**/*'](ルートからの全てのファイル) という指定だったため)。

うっかり走らせないこと。

参考

(余談) エントリーポイントの ignore 指定

webpackのentryファイルを複数指定、globパッケージの使い方 - Qiita

続・ Gulp 4 + Webpack 5 を試す (resolutions 使用)

2020-11-24T23:34:09+09:00

以前、Gulp 4 + Webpack 5 を試す ( 未完 / terser-webpack-plugin で TypeError: Cannot read property ‘javascript’ of undefined エラーになる)の記事で Gulp 4 + Webpack 5 の実験をしましたが、その続きです。

経緯

BackstopJS を試す (Error: Failed to launch the browser process! エラー発生→ puppeteer のバージョンを指定して解決)で package.json に resolutions を記述して Yarn で内部依存パッケージのバージョンを強制的に変更する手法を取りましたが、同様の手法が使えるのではないか、と思った次第です。

検証

package.json

```json:package.json
// 略
"devDependencies": {
// 略
"webpack": "^5.6.0",
"webpack-stream": "^6.1.1",
"terser-webpack-plugin": "^5.0.3",
// 略
},
"resolutions": {
"webpack": "^5.6.0"
},
// 略


上述のように `resolutions` で Webpack のバージョンを指定。

### gulp/tasks/js.js

`gulp/tasks/js.js` は前回のまま。

### webpack.config.js

`webpack.config.js` は source map のための設定を追加した以外はそのままです。

```javascript:webpack.config.js
const _         = require('./gulp/plugin');
const dir       = require('./gulp/dir');

const mode = () => {
    return process.env.DEV_MODE === 'dev' ? 'development' : 'production';
};
const modeFlag = () => {
    return process.env.DEV_MODE === 'dev' ? false : true;
};
const entry = () => {
    const entries = _.glob
        .sync(
            '**/*.js',
            {
                ignore: [
                    '_plugins/**'
                ],
                cwd: dir.src.js
            }
        )
        .map(function (key) {
            return [key, _.path.resolve(dir.src.js, key)];
        });
    return Object.fromEntries(entries)
};
const configs = {
    mode: mode(),
    entry: entry(),
    output: {
        filename: '[name]'
    },
    optimization: {
            minimizer: [
            new _.webpackTerser({
                extractComments: 'some',
                terserOptions: {
                    compress: {
                        drop_console: modeFlag(),
                    },
                },
            }),
        ],
    }
};
if (process.env.DEV_MODE === 'dev') {      // 追加
    configs.devtool = 'inline-source-map';
}

module.exports = configs;

これで yarn restart などすると

$ gulp

# 略

[hh:ii:ss] asset app.js 226 KiB [emitted] [minimized] (name: app.js) 1 related asset

webpack 5.6.0 compiled successfully
[hh:ii:ss] Finished 'jsBuild' after 20 s

動きました！

後々は resolutions なしでも動くようにしたいですが、ひとまず動く形になったのでメモしておきます。

参考

Yarn の reasolutions

yarn: resolutions で依存の依存のバージョンを指定する - nju33

Gulp 4 + Webpack 5 を試す ( 未完 / terser-webpack-plugin で TypeError: Cannot read property 'javascript' of undefined エラーになる)

2020-11-24T23:28:18+09:00

以前、browserify + babelify + Gulp で IE11対応を試すの記事で browserify + babelify を試しましたが、今回は Webpack に挑んでみます。

ただし、プレーンな Gulp 環境ではなく、 Ususama で。

コード

package.json

// 略
    "devDependencies": {
// 略
        "glob": "7.1.6",
        "webpack": "^5.1.3",
        "webpack-stream": "^6.1.0",
        "terser-webpack-plugin": "^5.0.0",
// 略
    }
// 略

gulp-uglify-es と gulp-concat を除き、代わりに webpack 本体と Gulp で Webpack を使用するために必要な webpack-stream 、そして minifier の terser の Webpack 用プラグインである terser-webpack-plugin を追加。

gulp/tasks/js.js

const gulp          = require('gulp');
const plumber       = require('gulp-plumber');
const notify        = require('gulp-notify');
const webpack       = require('webpack');
const webpackStream = require('webpack-stream');
const rename        = require('gulp-rename');
const dir           = {
    dist: {
        js: './dist/js'
    }
};

const webpackConfig = require('../../weppack.config');

const jsBuild = () => {
    return _.webpackStream(webpackConfig)
        .pipe(_.plumber({
            errorHandler: _.notify.onError({
                message: 'Error: <%= error.message %>',
                title: 'jsLibBuild'
            })
        }))
        .pipe(_.rename((path) => {
            path.basename += '.min'
            path.extname = '.js'
        }))
        .pipe(_.gulp.dest(dir.dist.js));
};

module.exports = jsBuild;

webpack.config.js

const webpack       = require('webpack');
const webpackTerser = require('terser-webpack-plugin');
const path          = require('path');
const glob          = require('glob');
const dotenv        = require('dotenv').config();
const dir           = {
    src: {
        js: './src/js'
    }
};

const mode = () => {
    return process.env.DEV_MODE === 'dev' ? 'development' : 'production';
};
const modeFlag = () => {
    return process.env.DEV_MODE === 'dev' ? false : true;
};
const entry = () => {
    const entries = _.glob
        .sync(
            '**/*.js',
            {
                ignore: [
                    '_plugins/**'
                ],
                cwd: dir.src.js
            }
        )
        .map(function (key) {
            return [key, _.path.resolve(dir.src.js, key)];
        });
    return Object.fromEntries(entries)
};
module.exports = {
    mode: mode(),
    entry: entry(),
    output: {
        filename: '[name]'
    },
    optimization: {
            minimizer: [
            new _.webpackTerser({
                extractComments: 'some',
                terserOptions: {
                    compress: {
                        drop_console: modeFlag(),
                    },
                },
            }),
        ],
    }
};

いくつかの記事を参考にしながらタスクを組みます。

自分でカスタマイズした部分は以下。

.env で dev, demo, prod のモードを切り替えているので、その部分を process.env.DEV_MODE で振り分け
- Webpack の設定の mode と terser-webpack-plugin の drop_console のフラグが関係しています
複数の .js ファイルをエントリポイントにしたかったのでその部分はwebpackのentryファイルを複数指定、globパッケージの使い方 - Qiitaを参考に
最終的なファイル名は XXX.min.js の形にしたかったので gulp-rename を通しました

jQuery の扱い

タスク自体は上記のやり方で走ることが確認できました( DEV_MODE=dev )。

次は現時点ではまだ jQuery を使用しているので、 jQuery をどう読み込ませるかが課題ですが、以下のようにして動作することを確認しました。

app.js

import $ from 'jquery';
import 'jquery.easing/jquery.easing';

$(() => {
    /* 処理 */
});

sitesearch.js

import $ from 'jquery';
import List from 'list.js';

//サイト内検索
export default () => {
    const options = {
        valueNames: ['searchTitle', 'searchText'],
    };
    const searchList = new List('listSearch', options);
    //hits
    searchList.on('searchComplete', function (a) {
        $('#hits').text(a.matchingItems.length);
    });
};

サイト内検索で List.js を使用しているのですが、これについてはHow am I suppose to import list.js with es6 and webpack ? · Issue #559 · javve/list.jsの Issues の方法で解決しました。

ここまでは比較的順調でした。

しかし、間も無く壁に突き当たることになります……。

TypeError: Cannot read property 'javascript' of undefined エラー

DEV_MODE=dev で動作することは確認できたので、 DEV_MODE=prod に切り替えました。

すると、以下のエラーが出てしまいました。

TypeError: Cannot read property 'javascript' of undefined
    at PATH\TO\PROJECT\node_modules\terser-webpack-plugin\dist\index.js:366:38

DEV_MODE=dev に戻すと先ほどと同じように問題なく動作。上記でこのフラグが関係するのは mode と terser-webpack-plugin の drop_console の2箇所なので、そのどちらかだろうとアタリを付けます。

試しに drop_console を常に false としましたが、 DEV_MODE=prod でエラーは再現しました。

となると、 mode の方ということになります。

ここでエラー文で検索すると、以下の Issues を発見。 terser-webpack-plugin 本家のリポジトリです。

TypeError: Cannot read property 'javascript' of undefined ・ Issue #335 ・ webpack-contrib/terser-webpack-plugin

発生個所も含めてエラー文が同じです。

別の方のコメントを見ると、原因は以下の模様。

terser-webpack-plugin 5 は Webpack 4 とは互換性がない
webpack-stream の内部で使用している Webpack がバージョン 4 系

yep, we are working on it, release with fix will be today/tomorrow

TypeError: Cannot read property 'javascript' of undefined ・ Issue #335 ・ webpack-contrib/terser-webpack-plugin (2020/10/16日 22:04 JST)

わりとタイムリーなものを踏んでしまったようなので、 fixed されるのを待つ感じですかね……。

参考

Gulp + Webpack

webpack-stream

webpack-stream - npm

Webpack, 複数エントリポイントとoutput

webpackのentryファイルを複数指定、globパッケージの使い方 - Qiita

List.js import

How am I suppose to import list.js with es6 and webpack ? · Issue #559 · javve/list.js

terser-webpack-plugin

TypeError: Cannot read property 'javascript' of undefined ・ Issue #335 ・ webpack-contrib/terser-webpack-plugin

Nuxt.jsでMarkdownファイルからFAQページなどを作れるようしてみた(.mdファイル内でコンポーネントも使える)

2019-09-11T12:01:00+09:00

ほそぼそと作っているWebサービスの積読ハウマッチ、
Gigazineさんに紹介されました🎉🎉🎉

おかげさまでユーザやアクセスが増えたのですが、
問い合わせやコメントも急増したので、FAQを用意したほうがいいなと...

Nuxt.jsのページのうち、FAQのような静的なページだけ、
Markdownで作成できないかを調査したときの備忘録。

環境はnuxt(2.8.1) / typescript(3.6.2)

ちょっと長めですが...

Markdownだけのシンプルな方法と
Markdown内でVueコンポーネントを使う凝った方法

の2パターンをまとめています。

これを使うと一部のページをマークダウンで書けるので、
FAQとか以外にブログとか記事とかも簡単にmarkdownで書けるようになるかもと。

長めですが、見出しとソースコードを見てくとだいたい分かるかも。

できあがったもの: 1.シンプルな方法

こんな感じのMarkdownファイルを読み込んで

# よくある質問 / FAQ

## 積読本しか登録してはいけないのですか？

そんなことないです！**読み終わった本だけでも OK です ♪**
まだ積読ハウマッチで**誰も登録していない本**もあるので、
**おすすめの本**などあればどんどん登録してみてください！

また、同じ本を読んでいる人や積んでる人もわかるので、
**本の好みが近い人が見つかるかも知れません** 😊

こんな感じの画面を作れちゃいます!

できあがったもの: 2.凝った方法

ツイートを埋め込めるよう、Markdownファイルの中で
vue-tweet-embedを利用しています。

# 更新情報

## 2019/09/09 　洋書検索に対応 ✨

1.の方法だとタグがそのままのため、なにも表示されませんが、
2.の方法だと、こんな感じの画面を作れちゃいます!

ここから、それぞれの方法の説明

1. Markdownだけのシンプルな方法

シンプルな方法はこんな感じ

Markdownファイルを読み込んで、
markedでHTML化して、
v-htmlでHTMLを挿入

Nuxt.jsでは、Markdownファイル(.md)のようなファイルを
そのまま取り込む方法が無いので、
Webpackプラグインのraw-loaderを使います。

raw-loaderなどのインストール

必要なパッケージをインストール

$ npm install --save raw-loader marked highlightjs

nuxt.config.jsの設定

.mdを読み込む際に、raw-loaderを使うように設定。

import NuxtConfiguration from "@nuxt/config";

const config: NuxtConfiguration = {
  build: {
    extend(config, ctx) {
      if (!!config.module) {
        // .mdファイルだったら、raw-loaderを使うように設定
        config.module.rules.push({ test: /\.md$/, use: ["raw-loader"] });
      }
    }
  },
}

.vueはこんな感じ

これだけで、.mdファイルを読み込んでページが作れちゃいます！
あとは読み込むファイルを変えるだけで、簡単に静的なページを量産(´ω｀)

そのままだといい感じの見た目にならないので、
class="marked"のようにしておいて、
markdown用のCSSを設定していけばOK。

どんなCSSがいいかは、前の記事を参照ください。

注意: ハマった点...

2つ注意というか、ハマった点...

A) .mdファイルを読み込むときはrequireを使う

ぼくの環境だけかも知れませんが、
import mdText from "~/assets/faq.md"とすると
VSCode上でエラーがきませんでした。。
TypeScriptの設定やVeturの問題？

そのため、requireを使い、
const mdText = require("~/assets/faq.md");
としてます。

それによりモジュールとして読み込まれてしまうため、
mdText.defaultでテキストを取得しています。

(本当はimport文がいいんですが、あきらめてrequireに...)

B) v-htmlで挿入したHTMLにScoped CSSが効かない

VueでScoped CSSを使う場合、data-v-*属性が付与されますが、
v-htmlでHTMLを挿入しているため、その属性がついていません。。

これにより、Scoped CSSが効かないため、
markdown用のCSSを利用する際はグローバルで設定する必要があります。

(これでだいぶハマりました...)

2. コンポーネントを使う凝った方法

1.の方法で、ツイートを埋め込んでみようと思ったらうまく行かず...
vueでツイートを埋め込むには、vue-tweet-embedが必要なようで、
以下のようにしてみたら、

# 更新情報

## 2019/09/09 　洋書検索に対応 ✨

こんな感じに...

ツイッターで、

Vueのv-htmlのテキストにコンポーネントをいれることってできないかなぁ？markdownのなかにコンポーネント書けると色々便利そう。。
— 積読ハウマッチ📚きらぷか (@kira_puka) September 9, 2019

と悩んでたところ、@mizuki_rさんから、こんなアドバイスが(´ω｀)

v-htmlだとvueの解釈は出来ないので、独自のdirective定義してvueをコンパイルできるようにしたことはあります

vueのtemplateオプションはHTML文字列を渡してvueのcomponentとしてcompileします。つまり、directiveで受け取ったHTML文字列をvueのtemplateオプションに渡してvueのコンポーネントを作ると…？

なるほど...( ﾟдﾟ)!

大まかな流れ

カスタムディレクティブを用意
カスタムディレクティブ内でコンポーネントを作成し、
コンポーネントのtemplateにmarked()のHTMLを渡して、
Vueのコンパイル(=$mounte()の呼び出し)
Vueのコンパイルした結果からHTML要素を取得($el)して、
カスタムディレクティブを設定したHTML要素の子に挿入(el.appendChild(instance.$el))

長いし、複雑...

.vueはこんな感じ

.vue自体はほぼ同じ。
v-htmlがカスタムディレクティブのv-mdに変わってるだけ。

とりあえず、vue-tweet-embedのインストール

とりあえず、vue-tweet-embedを使うのでインストール

$ npm install --save vue-tweet-embed

カスタムディレクティブ内で動的コンパイル

カスタムディレクティブの用意していく。~/plugins/v-md.tsに作成

import Vue from "vue";
import { Tweet } from "vue-tweet-embed";

Vue.directive("md", {
  inserted: function(el, binding) {
    // v-md="value"のvalue部分を取得
    const val = binding.value;

    // コンポーネントを作成。ルートが1つになるようにで囲む
    // Tweetをコンポーネントで使うので、componentsも設定
    const cmp = Vue.extend({
      components: { Tweet },
      template: `${val}`
    });

    // Vueコンポーネントをコンパイルして、インスタンスを取得
    const instance = new cmp().$mount();

    // インスタンス化からHTML要素を取得して、
    const element = instance.$el
    // カスタムディレクティブを設定したHTML要素の子に挿入
    el.appendChild(element);
  }
});

作ったプラグインをnuxt.config.tsに追加

作ったプラグインを有効にするため、nuxt.config.tsに設定を追加

import NuxtConfiguration from "@nuxt/config";

const config: NuxtConfiguration = {
  plugins: [
    { src: "~/plugins/v-md", ssr: false },
  ],
}

これでいけるかと思いきや...

まっしろ(´ω｀)
タイトルすら出ない...

Consoleを見るとエラーが...

error [Vue warn]: You are using the runtime-only build of Vue where the template compiler is not available. Either pre-compile the templates into render functions, or use the compiler-included build.

メッセージを見てみると、
「ランタイム限定なのでコンパイルできないよ！」
とのこと...なるほど...

このあたりを見てみると、「ランタイム + コンパイラ」を選択できるので、
nuxt.config.tsの設定を変更していく。

実行時にコンパイルできるように設定を変更

公式ドキュメントの「さまざまなビルドについて」を見ると、
vue/dist/vue.commonを使えば良さそう。

なので、buildに以下の3行を追加。

import NuxtConfiguration from "@nuxt/config";

const config: NuxtConfiguration = {
  plugins: [
    { src: "~/plugins/v-md", ssr: false },
  ],

  build: {
    extend(config, ctx) {
      if (!!config.module) {
        config.module.rules.push({ test: /\.md$/, use: ["raw-loader"] });
      }

      // 「ランタイム限定」から「ランタイム + コンパイラ」に変更
      if (!!config.resolve && !!config.resolve.alias) {
        config.resolve.alias["vue$"] = "vue/dist/vue.common";
      }
    }
  },
}

すると...

出た(´ω｀)!!

注意: 未解決...

1点対応していない部分が...
Markdownファイル内でを使うと、エラーが...

app.js:1971 Uncaught TypeError: Cannot read property 'resolve' of undefined

Nuxt側からcontextやvue-routerの情報を渡していないためだと思いますが、
詳しく見れていませんが、nuxt-linkを使うとエラーになるため、ご注意ください...

おわりに

marked+highlightjs+raw-loaderを使って、
Markdownファイルでページコンテンツを作れるように!

カスタムディレクティブを使うと、
Markdownファイル内でVueコンポーネントを使えるように!

今回のアップデートでFAQや更新情報のページに利用してますが、
サイトの説明や使い方ページなどにも使えたり、
Nuxt.jsアプリにmarkdownで書いた記事なども簡単にできそう(´ω｀)

こんなのつくってます！！

上記を使ってFQAや更新情報ページを追加した、積読用の読書管理アプリ「積読ハウマッチ」！
積読ハウマッチはNuxt.js(SPA)+Firebaseで開発してます!

もしよかったら、遊んでみてくださいヽ(=´▽`=)ﾉ

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで♪

SP☆12参考表(地力表)支援サイトを支える技術

2018-12-03T23:42:44+09:00

SP☆12参考表(地力表)支援サイトを支える技術

この記事はcrieitでの個人開発サービスに用いられている技術 Advent Calendar 2018 の9日目の記事です。
昨日はckoshienさんの野球リーグスコア管理システムに用いている技術についてという記事でした。
明日はiotas𓆡創作支援アプリ運営中𓅬さんの記事です！

SP☆12参考表(地力表)支援サイトとは

ゲームセンター等でプレイできるbeatmania IIDXというゲームの成長支援サイトです。
2014年11月に開発を開始し、運用を始めて4年ほど経過しました。
現時点で登録者数は9200人ほどで、GAのマンスリーアクティブユーザは11k人ほどです。

beatmania IIDXは音ゲーと呼ばれるジャンルのゲームで、楽曲に難易度が設定されています。
楽曲の難易度はおおまかに言うと☆1から☆12までに分類されます。

この分類はシングルプレイ(SP)、ダブルプレイ(DP)といったモードごとに存在しているのですが、本サイトではその中でもSPの☆12についてだけ取り扱ってます。

なお、このサイトはGitHub上でpublic repositoryとして公開しています。
参考になったらスターをいただけるとモチベーションになります。

なぜSP☆12だけなのか

ここではゲーム性の説明を行います。
技術的な話を知りたい方はスキップしてもらって構いません。

SP☆12は現時点で(未解禁のものも含めると)300曲を超えています。
そして他の難易度帯と比較すると☆12は易しい曲と難しい曲の難易度差が最も激しくなっています。
☆12に挑戦し始めの人は噂程度に「この曲は☆12の中でも難しいと言われている気がする…」という選曲判断が必要になってきます。
公式にも指標に近いものがあるのですが、割とあてにならないという背景もあります。
※ 人によって得意不得意分野があるため参考表も万人に当てになるわけではないです

また、☆12の攻略には長い時間が必要になります。
自身の例ですと、1つのゴールであろう皆伝という最上位段位の取得に☆12触り始めから1年以上の時間が必要でした。
皆伝という段位は☆12の中でも上位の難しさに位置している楽曲で構成されるコースのため、簡単な☆12からスタートし、段階を踏んで難しい☆12もクリアできるようになる必要があります。

私の元々の開発モチベーションとしては、このステップをモチベを維持しつつ「続けていける」ようにすることでした。
そのため自分がプレイしているSPであり、皆伝を取得するのに避けられない☆12を対象としたサイトを作り始めました。

スタート地点としてはPHPで簡易的な☆12参考表サイトを作成していました。
このサイトは知人等にインターナルに利用してもらっていたのですが、需要がありそうということで公開を前提に作り直し始めたのが2014年11月です。

採用している技術たち

ざっくりと書くと、

サーバ
- [email protected]
- Sidekiq
- [email protected]
フロント
- [email protected]
- React/Redux
- ImmutableJS
インフラ
- さくらVPS(2コア、4GB、SSD 50GB)
- (ローカル環境のみ)k8s対応
- nginx
- god
- mackerel
- BigQuery(アクセスログ解析)

といった形になっています。
AWS/GCP等も検討したことはあるのですが、VPSと比較すると月額コストが跳ね上がるため見送っています。

技術的な解説

はじめてRailsを使って作成したアプリだったことによるイマイチコードがいたるところに点在しています。
合間を見て少しずつ改善はしているものの既にユーザが利用していると変更しにくい部分があり、手がつけにくいところもあります。
特にRailsのroutes.rbの記法の修正は既にブックマークをしているユーザへの影響を考えると変更しにくいです。

一度ルーティングの変更をリダイレクトサポートをしながら変更したことがあったのですが、1年半ほどそのページを開くとリダイレクトしつつnoticeでブックマークの変更を促していたにも関わらず、いざサポートを切るとdead linkを参照してしまう方は想像より多かったのを記憶しています。

技術的な要素でいうと、「いたって普通なRailsアプリ」をメインポリシーとして作成しています。
特殊なことをいろいろと行うと、その分メンテナンスコストも上がるため極力Rails Wayに乗っておこうという精神です。
メインで開発し続けているサービスなら多少の獣道も選択としてはありですが、社会人が片手間に行う分には大衆に乗っかるほうが楽でした。

最近まではフロントエンドとの連携に自作のgem使ったりしながら特殊なことをしていたのですが、
そのあたりはwebpackerに乗り換え、スタンダードRailsへの変身しました。
(この変身コストはとても大きかったです。。)

webpacker 4.0.0.pre.3

webpackerのstable releaseとしては3系ですが、このプロジェクトでは4系を利用しています。
理由としては最新のts-loaderを使いたかったためです。

ts-loaderの最新を利用するためにはwebpack4系である必要があるのですが、stable releaseのwebpackerではwebpack3系までしか対応していなかったためです。

webpackerを採用した理由としては「現在はRailsの中でそれが主流」という理由以上のことはありません。
疎なwebpackインテグレーションを自作しても良かったのですが、メンテナンスを続けるモチベが持てなさそうなので敬遠しました。
実際使ってみると細かいところで不満はあるものの、トータル的には体感は悪くないという印象を受けました。

webpackerでは下記のように少しだけ設定を変えています。

process.env.NODE_ENV = process.env.NODE_ENV || 'production'

const environment = require('./environment')

module.exports = environment.toWebpackConfig()
module.exports.devtool = 'source-map'

といった設定にしてproductionでは devtoolの nosources-nource-map を source-map に置き換えていることです。
source-map自体を切る修正を入れる人が多そうな印象ですが、自分の環境ではあえて設定しています。
理由はsentryでのエラートラッキングが快適になるためです。

このような形でエラー部分の元ソースコードを表示することができます。
また raven-for-redux というnpmを利用することでそのときのactionやstateの状態までわかります。

そのエラーになるまでのactionの履歴

そのエラーが出たときのクライアント側のstate

OSSなので特にこのサービスに関しては隠蔽する必要はないのですが、mapファイルはsentryサーバ以外からアクセスできないようにしています。
自前でsentryを立てているので特定IPからのアクセスは弾くようになっています。

location ^~ /packs/ {
  gzip_static on;

  set $response_file 1;
  if ($request_uri ~ 'map$') {
    set $response_file 0;
  }
  if ($remote_addr = 'xxx.xx.xxx.xxx') {
    set $response_file 1;
  }
  if ($response_file = '0') {
    return 403;
  }
}

typescriptに置き換えてからまだ一度もエラーが出ていなかったため、この画面は意図的にエラーを仕込んで発生させました…ｗ

今のところ、webpacker4系に対する不具合は踏んでおらず問題なく運用できています。

react-rails

Reactとのつなぎ込みにはreact-railsというgemを利用しています。
react_on_railsというgemのほうが多機能なのですが、相容れないところがありreact-railsを採用することにしました。

react_on_railsのほうが優れている点としてはrailsContextというオブジェクトが付与されており、
この中にtimezone/localeなどを始めとした開発者がほしいであろうメタ情報が入っています。
またRailsにxhrリクエストをする際にcsrf-tokenをheaderにセットするAPIも用意されています。

ただcomponentをrenderするためのhookに turbolinks:render を利用しており、このhookではページがチャタるケースがあったため、採用しませんでした。

react-railsはreact_on_railsと比べると非常にシンプルで、コンポーネントをrenderする以上のサポートはあまりないようです。
ただそれを行ってくれるだけで自分の要件的には十分だったため、採用しています。
react-railsではcomponentをrenderするhookに turbolinks:load を採用しています。

チャタるとは何かをもう少しわかりやすく言うと、一瞬古いページが表示された後に新しいページが表示される現象のことを指しています。

コンテンツが一瞬表示される->白くなる->再度表示されるというループになっていることがわかると思います。
一瞬表示された後と再度表示された後でAPIリクエストが2回走ってしまうという問題やUXの観点から許容できない、という判断になりました。

上記はturbolinks的には「仕様」の挙動です。
GitHub - turbolinks/turbolinks: Turbolinks makes navigating your web application faster から抜粋すると以下のように書かれています。

turbolinks:renderfires after Turbolinks renders the page. This event fires twice during an application visit to a cached location: once after rendering the cached version, and again after rendering the fresh version.

react_on_railsのgem自体にはissueを投げてみたのですが、少し私の想像を超えた範疇の問題があるらしく、今回はreact-railsを採用することにしました。

ts-routes

Railsとフロントの繋ぎ込みには GitHub - bitjourney/ts_routes-rails: Exports Rails URL helpers to TypeScript, inspired by js-routes というgemを利用させていただきました。
似たようなgemにjs-routesと呼ばれるものがあり、そちらを採用していたのですがts化にあたって載せ替えを行っています。
パラメタ不足などの不正なルーティングに関して検知しやすくなるため、tsとrailsを組み合わせるならお薦めです。

Sidekiq

兄弟サイトのIST(Iidx Score Table)からのデータ取り込みを始めとした外部サービスの連携や定期処理(sidekiq-cron)などに利用しています。

先述した通り☆12の譜面はかなり数が多く、1年を通して「解禁」され数が増え続けていきます。
これらを全て人手によって捕捉し続けるのはコストが高い、と感じ1日に1回IST側のデータを利用して新規の☆12が解禁されたら自動追加するようにしています。
ただ☆12の中での難易度自体は議論によって決められるもののため、難易度が決定した後の反映処理は人手で行っています。

当サイトはVPS1台で運用しているので、バックアップ等の日次処理も必要になってきます。
これらの処理もSidekiq側に任せています。
abilitysheet/service_dumper.rb at master · 8398a7/abilitysheet · GitHub というlibを作り、

DBのdump(pg_dump)
carrierwaveで保存された画像等の収集

を行った後にtar.gzに固めてS3に送る処理です。
これらの処理をjobにして朝の5時過ぎに行うようにしています。
また、手元でproduction環境の再現を行いたいときにもS3からデータを取ってきています。

運用しているいくつかのサービスは全てこのような形でバックアップを取っており、いつVPSが死んでしまってもすぐにサービスを復旧できるようにしています。

CI

CircleCIを使ってテストを行っています。
テストフレームワークはrspecでjs部分のテストはjest等では書いていません。
代わりにsystem specとしてchromedriverを利用したE2Eで担保しています。
昔に書いたコードなので、コントローラ系のspecも多いですがこのあたりも粛清したいところです…ｗ

system specではjsを使うところ使わないところで以下のように条件分岐を書いています。
systemであっても js: true でないところは rack_test で行うようにしているところと、NO_HEADLESS という環境変数を定義して実行するとchromeが実際に立ち上がるようにしています。

  config.before(:each, type: :system) do |example|
    if example.metadata[:js]
      if example.metadata[:iphone6]
        display_size = [375, 667]
        args = %w[--headless --disable-gpu --user-agent=iPhone]
      else
        display_size = [1920, 1080]
        args = %w[--headless --disable-gpu]
      end
      args.shift if ENV['NO_HEADLESS']
      caps = Selenium::WebDriver::Remote::Capabilities.chrome(chromeOptions: { args: args })
      driven_by :selenium, screen_size: display_size, options: { desired_capabilities: caps }
    else
      driven_by :rack_test
    end
  end

実行する際には NO_HEADLESS=true bundle exec rspec spec/systems といったコマンドで実行します。
spec内に binding.pry を仕込むことでElementも触れるのでspecがうまくいかないときの不具合調査などに利用しています。

運用サポート

死活監視にはmackerelとgodを利用しています。
Mackerel（マカレル）: 新世代のサーバ管理・監視サービスはSaaS型のサービスでプロセスが死んでいるか生きているかの監視もできます。

死活監視の肝としては God - A Process Monitoring Framework in Ruby を採用しています。
sidekiq/puma/redis/postgresql/nginxなどのサービス継続に必要なプロセスは全てgodに監視させています。
再起動時などにもgodに任せて起動させているため、再起動するとサービスが落ちたままになっているということもないです。

特にsidekiqは知らない間にメモリの使いすぎでプロセスが落ちていることもあったため、godに監視させて死んでいたら起こすようにするのは精神的安定感が増し増しでした。
デプロイには capistrano を採用していますが、こいつはsidekiqのgod監視とやや相性が悪いです。
pumaと違ってgraceful restart時にプロセスがいない瞬間ができてしまうため、
capistranoがsidekiqを起こすのとgodがsidekiqを起こすのが衝突してしまい、二重でsidekiqが起動してしまうケースが有るためです。
capistranoと併用する場合は素直にcapではsidekiq:stopだけして起こすのはgodに任せたほうが良いという感覚を持っています。
abilitysheet/deploy.rb at master · 8398a7/abilitysheet · GitHub

k8s

k8sもローカル環境での動作自体はサポートしています。
VPSを2台所持しているため、2台でなんとか運用できないか検討していたのですが、結局2台では割と厳しいということと、
capistranoに代わるデプロイツールを自作し、メンテし続けるコストを払える自信がなかったため見送りました。

一通りproductionとしてローカル環境で動作させるところまでは確認しているのでrailsでのk8sに参考にしたい方はどうぞ。
abilitysheet/kubernetes at master · 8398a7/abilitysheet · GitHub
ただ運用もしていないコードなので穴はたくさんあると思います…

BigQuery

nginxのアクセスログをfluentd経由でBigQueryに投げるようにしています。
SSDで容量が厳しく、割と細かめにログを削除しているため後でまとめて見るためにBigQueryを利用しています。

元々はS3に置いてAthenaで集計していたのですが、BigQueryのほうがいろいろと捗りそうなので移管しました。
GitHub - kaizenplatform/fluent-plugin-bigquery というプラグインを利用させていただき、bqにログを送っています。

主にARのconnection poolがタイムアウトになっていたり、急激な負荷によるアラートの調査などに使っていたりします。
railsユーザであればnginxのltsvログに 'request_id:$sent_http_x_request_id\t' を追加しておくことで、調査が捗ることがあるためおすすめします。
nginxのログから問題のrequest_idがわかればproduction.logをrequest_idでgrepすることで該当行のログに辿り着きやすくなります。

おまけ IE対応

最近webpackerベースのreactにリプレースを行っていたのですが、その際に困った問題と解決した手法についても記載しておきます。

tsconfig.json ではtargetをes5としていましたが、babel-polyfillを仕込み忘れていたことが1点目です。
記法自体はes5まで落としてくれるのですが、polyfillがないと Promise などがIEにはないため正常に動作しません。
polyfillの入れ方に関しては、headerに https://cdn.polyfill.io/v2/polyfill.min.js を追加するのがおすすめです。
ブラウザのUAを見て必要なpolyfillを行ってくれます。
試しにIEで見ると結構な量をpolyfillしてくれますが、最新版のchromeではほぼ空であることが確認できると思います。
自分でbundleすると配布するjsファイルが巨大化するため、cdn経由で入れることにしました。

2点目はes5にトランスパイルされていないライブラリを利用してしまっていることでした。
query-stringというライブラリでquery-string/index.js at master · sindresorhus/query-string · GitHubの行でアローファンクションを使っているのですが、これがIEだと解釈できないという問題です。
webpackerのbabel-loaderはexcludeで node_modules が指定されているため、使っているライブラリまではes5にトランスパイルされません。
よくよくドキュメントを見るとレガシーブラウザは5系を使え(最新は6系)ということが記載されていたので、5系を利用することで解決しました。

当初は上記2点の問題がわからぬまま、IEでは見れないといった声が上がっていたため、最初の対応としてはelectronでサイトをラップしたexeを配布していました。
それにはGitHub - jiahaog/nativefier: Make any web page a desktop applicationというライブラリを利用したのですが、幅広くの場面で役に立つので困ったら利用してみてください。

まとめ

今回はSP☆12参考表(地力表)支援サイトを支える技術をご紹介しました。
他にもいくつかサービスがありご紹介したい技術もあったのですが、割と長くなってしまったので今回はこのような形で締めたいと思います。

サービスを運用している方の参考になれば幸いです。

GitHub - 8398a7/abilitysheet: This app is ability sheet for beatmania iidx music of level 12.

P.S. 作者は2018年5月に念願の冥ハードを成し遂げ、ゆるふわ離脱モードに突入しました。

初心者はWebpackの事は一度忘れた方が良い

2018-11-26T21:32:02+09:00

最近Webpackの初心者に対する話がちょこちょこ話題になっている。でも最近はWebpackへの理解がそこまで重要では無くなってきつつある感じがするので、適当にそのあたりのことを書いてみる。

ちなみに話題になったのは下記のスライドが発端。

なぜ初心者は webpackが解らないのか？- Why can’t you understand the webpack? -

あとこのあたりとか
Webpack の考え方について - mizchi's blog

ちゃんと知りたい人は当記事じゃなくて上記ふたつを見た方がいい。当記事は単なる雑記のため。仕事できっちりやらないといけない人には向かない内容。（そもそもWebpack初心者と、Web開発初心者という意味の違いがある）

そもそもWebpackとは何なのか

Webpackは大雑把に言えばプログラムを一つのファイルに纏めてくれるもの。

例えば、Windowsの実行ファイルなども色々なプログラムをビルドして一つのexeファイルになる。それと同じで、最終的に一つのjsファイルとかcssファイルとかにまとめられる。

実行ファイルではないので下記のような感じでHTML上で読み込まれる。

もしWebpackでまとめられていない場合、はるか昔などは上記のような読み込みを何行もかけて書いてたくさんのjsファイルを読み込んでいた。

初心者は特にWebpackのことを知らなくても何か作れる

Webアプリケーション用のフロントエンドのアプリケーションを開発する場合、最近はJavaScriptのフレームワークを使うことが主流になってきていると思う。

もちろんその時Webpackを使う必要があるのだが、だいたいフレームワークにラップされているため、最初はほとんど意識しなくても良くなっている。例えばNext.jsやNuxt.js、Angular等を利用する場合、だいたいプロジェクトを新規作成するためのCLI（vue-cliやAngular CLI、create-nuxt-app等）が用意されており、それを実行するだけで一通りプロジェクトの雛形を作ってくれ、すぐに動かせる状態にまでしてくれる。そのため、そもそもWebpackの設定を一から作ってプロジェクトを構築する、ということは必要ではなくなってきている。

PHPのフレームワークのLaravelですらLaravel MixというWebpackのラッパーが入っていて、全く意識すること無くVueを使っていくことができるようになっている。

そのような感じで今はWebpackを知らなくてもアプリケーションが作成できる。

もちろん細かい設定の変更や追加をする場合はWebpackの設定を弄らなければならない場面なども出てくるので、その段階になって少しずつわからないところや必要なところを調べていけばいいと思う。

Twitter上でも時々「Webpackを学び始めたけど分からない」みたいな発言を見かけたりするが、Webpackから入るのではなく、Webpackが梱包されているフレームワークから学び始める方が色々と近道になるような気がする。

まとめ

そんな感じでWebpackは触る機会が少なくなっていくのでは、という気がしている。個人的にもそれでよくて、余計なことは考えずアプリケーションの開発に没頭できる方がよいのでは、と思っている。

また例が極端だけどWindows用のアプリケーションを作るときだってだいたいVisual Studioが何となくあれこれ勝手にやってくれて、ちょこちょこ必要な設定をいじる以外はビルドの仕組みをあまり理解しなければならない、ということもない。Webpackもそういうものになっていくとよいかな…と思う。（とはいえ専用の開発用ソフトウェアがあるわけではくそこまでは行かないと思うので、今の通りちょこちょこいじっていかなければ行けない状態は続くと思うけど）

Gulp 4 で SCSS + Stylelint + Webpack + ESLint + Edge.js + BrowserSync なフロントエンド環境構築

2018-11-12T00:32:00+09:00

（ブログからのクロス投稿です。）

この記事では、Gulp 4でフロントエンドの開発環境を構築する方法を紹介します。Gulp 4をタスクランナーとして、CSSのトランスパイルに SCSS + Stylelint、JavaScript のトランスパイルに Webpack + ESLint、、テンプレートエンジンとして Edge.js、さらにローカルサーバーとして BrowserSync を組み合わせます。

私はどちらかというとサーバサイドな人でフロントエンド専門ではないのですが、モックアップ作ったりで HTML コーディングしたくなって、いまさらながら Gulp で自分なりの環境構築をしたので結果を共有します。

フロントエンドと言っても全面的に React や Vue でゴリゴリアプリケーションを書くというより HTML コーディングの範疇内でのユースケースを想定しています（フレームワークでゴリゴリしたいなら create-react-app とか vue-cli とか使うといいです）。

概要

サンプルコードも含めた設定の全体についてはこちらのリポジトリを参照してください。

依存パッケージ

https://github.com/MasahiroHarada/gulp-4-starter/blob/master/package.json

ちなみに開発環境は Node v10.7.0、npm v6.4.1 です。

ビルドコマンド

最終的なビルドコマンドは以下の通りです。

// 開発ビルド：監視モードで実行されます。
$ npm run dev

// 本番ビルド：JavaScript が圧縮されます。
$ npm run prod

ビルドタスク

gulpfile.babel.js

ES Modules（import/export）を使用したかったのでファイル名に .babel をつけて Babel のトランスパイルがかかるようにしました。

gulpfile.babel.js

import { series, parallel, watch } from 'gulp';

import { reload, serve } from './tasks/server';
import { styles } from './tasks/styles';
import { scripts } from './tasks/scripts';
import { templates } from './tasks/templates';
import { images } from './tasks/images';
import { clean } from './tasks/clean';

import {
  sass as sassConfig,
  scripts as jsConfig,
  images as imagesConfig,
  templates as templatesConfig
} from './tasks/config';

/**
 * ファイルの変更を監視
 */
function watchFiles() {
  // Sass
  watch(sassConfig.src, series(styles, reload));
  // Templates
  watch(
    [templatesConfig.edges, templatesConfig.data, templatesConfig.helper],
    series(templates, reload)
  );
  // JavaScript
  watch(jsConfig.src, series(scripts, reload));
  // Images
  watch(imagesConfig.src, series(images, reload));
}

/**
 * 開発用ビルド
 */
export const dev = series(
  clean,
  parallel(styles, templates, scripts, images),
  serve,
  watchFiles
);

/**
 * 本番用ビルド
 */
export const build = series(
  clean,
  parallel(styles, templates, scripts, images)
);

前述の通り gulpfile を ES2015 以降の構文で書くために Babel の設定ファイルも追加します。

.babelrc

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": { "node": "current" }
      }
    ]
  ]
}

タスクを色々書くと長くなってしまうので、個別のタスクはそれぞれ別ファイルに分け、tasks ディレクトリに格納しています。

それぞれ見ていきましょう。

設定ファイル

まずは設定ファイルです。パスの設定が入っています。

tasks/config.js

const ASSET_ROOT = 'src';
const DEST_ROOT = 'public';

export const sass = {
  src: `${ASSET_ROOT}/sass/**/*.scss`,
  dest: `${DEST_ROOT}/styles`
};

export const scripts = {
  srcRoot: `${ASSET_ROOT}/js`,
  src: `${ASSET_ROOT}/js/**/*.js`,
  dest: `${DEST_ROOT}/js`,
  babelrc: {
    presets: [['@babel/env', { targets: '> 0.25%, not dead' }]]
  }
};

export const templates = {
  root: `${ASSET_ROOT}/templates`,
  edges: `${ASSET_ROOT}/templates/**/*.edge`,
  pages: `${ASSET_ROOT}/templates/pages/**/*.edge`,
  data: `${ASSET_ROOT}/templates/data.json`,
  helper: `${ASSET_ROOT}/templates/helper.js`,
  dest: DEST_ROOT
};

export const images = {
  src: `${ASSET_ROOT}/images/**/*.*`,
  dest: `${DEST_ROOT}/images`
};

export const isProd = process.env.NODE_ENV === 'production';

BrowserSync

ファイルの変更を検知して自動でブラウザをリロードさせるため、BrowserSync のタスクを作成します。設定方法はこちら（Minimal BrowserSync setup with Gulp 4）を参考にしました。

tasks/server.js

import browserSync from 'browser-sync';

const server = browserSync.create();

/**
 * 開発用サーバ再起動
 */
export function reload(cb) {
  server.reload();
  cb();
}

/**
 * 開発用サーバ起動
 */
export function serve(cb) {
  server.init({
    server: {
      baseDir: './public'
    }
  });
  cb();
}

Clean

ファイルの出力前に出力先の既存ファイルを削除しておくためのタスクです。

tasks/clean.js

import del from 'del';

/**
 * 出力先のディレクトリを空にする
 */
export function clean() {
  return del(['public']);
}

スタイル

スタイルに関しては2つのタスクを定義しています。

まず1つめはSCSS を CSS に変換するためのタスクです。ソースマップ生成（gulp-sourcemaps）とファイル圧縮（gulp-clean-css）も実行しています。

2つめは CSS（今回は SCSS）の構文チェックツール Stylelint を実行するためのタスクです。gulp-stylelint を使用します。またファイルの監視中に毎回すべてのファイルを lint せず変更があったファイルのみチェックするために gulp-changed-in-place というプラグインも使用します。

tasks/styles.js

import gulp from 'gulp';
import gulpSass from 'gulp-sass';
import sourcemaps from 'gulp-sourcemaps';
import cleancss from 'gulp-clean-css';
import plumber from 'gulp-plumber';
import gulpStylelint from 'gulp-stylelint';
import changed from 'gulp-changed-in-place';

import { sass as config, isProd } from './config';

/**
 * SCSS -> CSS
 */
export function sass() {
  return gulp
    .src(config.src)
    .pipe(plumber())
    .pipe(sourcemaps.init())
    .pipe(gulpSass().on('error', gulpSass.logError))
    .pipe(cleancss())
    .pipe(sourcemaps.write('.'))
    .pipe(gulp.dest(config.dest));
}

/**
 * Stylelint
 */
export function stylelint() {
  return gulp
    .src(config.src)
    // firstPass は初回実行時に全ファイルを対象とするかどうかのオプション
    .pipe(changed({ firstPass: true }))
    .pipe(gulpStylelint({
      failAfterError: isProd,
      reporters: [{ formatter: 'verbose', console: true }],
      syntax: 'scss'
    }));
}

export const styles = gulp.series(stylelint, sass);

Stylelint の設定ファイルです。

```json:.stylelintrc
{
"extends": "stylelint-config-standard",
"plugins": ["stylelint-order"],
"rules": {
"order/properties-alphabetical-order": true
}
}


### 画像圧縮

[gulp-imagemin](https://github.com/sindresorhus/gulp-imagemin) を使って画像圧縮を行うタスクです。

オプションはお好みでどうぞ。

tasks/images.js

```js
import gulp from 'gulp';
import imagemin from 'gulp-imagemin';

import { images as config } from './config';

export function images() {
  return gulp
    .src(config.src)
    .pipe(imagemin())
    .pipe(gulp.dest(config.dest));
}

Edge.js → HTML

テンプレートエンジン Edge.js のファイルを HTML に変換するためのタスクです。

Edge.js について詳しくはこちらの記事もご覧ください。

tasks/templates.js

import gulp from 'gulp';
import edge from 'edge.js';
import tap from 'gulp-tap';
import rename from 'gulp-rename';
import fs from 'fs';
import path from 'path';

import { templates as config } from './config';

/**
 * Edge.js -> HTML
 */
export function templates() {
  // テンプレートを読み込む
  edge.registerViews(path.join(__dirname, `../${config.root}`));

  // データファイルを読み込む
  const data = fs.existsSync(config.data)
    ? JSON.parse(fs.readFileSync(config.data, 'utf8'))
    : {};

  // ヘルパー関数を読み込む
  fs.existsSync(config.helpers) && require(`../${config.helper}`);

  return gulp
    .src(config.pages)
    .pipe(
      tap(file => {
        const contents = edge.renderString(String(file.contents), data);
        file.contents = new Buffer(contents);
      })
    )
    .pipe(rename({ extname: '.html' }))
    .pipe(gulp.dest(config.dest));
}

JavaScript

タスク esTranspile は Webpack により JavaScript のトランスパイル〜バンドルを行います。

また esLint タスクではコードのチェックのために ESLint を実行します。gulp-eslint プラグインを使用します。

tasks/scripts.js

import gulp from 'gulp';
import gulpIf from 'gulp-if';
import plumber from 'gulp-plumber';
import gulpEslint from 'gulp-eslint';
import webpack from 'webpack';
import gulpWebpack from 'webpack-stream';
import changed from 'gulp-changed-in-place';

import { scripts as config, isProd } from './config';

export function esTranspile() {
  return gulp
    .src(config.src)
    .pipe(plumber())
    // gulp.watch と一緒に使う場合は第二引数が必須らしい。
    // https://www.npmjs.com/package/webpack-stream#usage-with-gulp-watch
    .pipe(gulpWebpack(require('../webpack.config.js'), webpack))
    .pipe(gulp.dest(config.dest));
}

export function esLint() {
  return gulp
    .src(config.src)
    .pipe(changed({ firstPass: true }))
    .pipe(gulpEslint())
    .pipe(gulpEslint.format())
    .pipe(gulpIf(isProd, gulpEslint.failAfterError()));
}

export const scripts = gulp.series(esLint, esTranspile);

Webpack の設定ファイルです。

webpack.config.js

import { scripts as config } from './tasks/config';

module.exports = {
  mode: process.env.NODE_ENV ? 'production' : 'development',
  entry: {
    app: `./${config.srcRoot}/app.js`
  },
  module: {
    rules: [
      { test: /\.js$/, use: 'babel-loader' }
    ]
  },
  output: {
    filename: '[name].js',
  },
  devtool: 'source-map'
}

複数のファイルを出力したい場合は、以下のように entry に追記すれば OK です。

entry: {
  app: `./${config.srcRoot}/app.js`,
  foo: `./${config.srcRoot}/foo.js`
},

こちらはESLint の設定ファイルです。

.eslintrc

{
  "extends": ["eslint:recommended"],
  "parserOptions": {
    "ecmaVersion": 6,
    "sourceType": "module"
  },
  "env": {
    "browser": true,
    "node": true
  }
}

フォーマッタ

フォーマッタはオマケです。お好みの設定＆エディタと連携していただければ。

EditorConfig

.editorconfig

root = true

[*]
end_of_line = lf
insert_final_newline = true

[*.{html,edge,scss,css,js,svg}]
indent_style = space
indent_size = 2

Prettier

.prettierrc

{
  "singleQuote": true
}

以上です。参考になれば幸いです。

「Webpack」の記事 - Crieit

【JS/Webpack】ビルドしたフォルダの不要ファイルを削除する

Webpack でバンドルしたライブラリを他の JavaScript から参照したい

webpack --watch で差分ビルドの完了時に任意のコマンドを実行する

Webpack (webpack-stream) で エントリーポイントを動的に変更する

Webpack の clean-webpack-plugin のメモ

続・ Gulp 4 + Webpack 5 を試す (resolutions 使用)

Gulp 4 + Webpack 5 を試す ( 未完 / terser-webpack-plugin で TypeError: Cannot read property 'javascript' of undefined エラーになる)

Nuxt.jsでMarkdownファイルからFAQページなどを作れるようしてみた(.mdファイル内でコンポーネントも使える)

SP☆12参考表(地力表)支援サイト を支える技術

初心者はWebpackの事は一度忘れた方が良い

Gulp 4 で SCSS + Stylelint + Webpack + ESLint + Edge.js + BrowserSync なフロントエンド環境構築

Webpack (webpack-stream) でエントリーポイントを動的に変更する

SP☆12参考表(地力表)支援サイトを支える技術