type-graphqlなプロジェクトをproductionモードでwebpackする

GraphQLサーバーをCode Firstで書いてみたくて、type-graphqlを使って見ました。
developmentモードでwebpackする分には何にも苦労なく動作するのですが、Herokuにデプロイするとさっぱり動きません。
あーでもない、こーでもないと、調べて見たところ、productionモードでwebpackする事が要因だという事に行き着きました。
productionモードでwebpackすると、コードの圧縮と難読化が行われます。
Code Firstでtype-graphqlすると言うことは、コードの圧縮と難読化されたコードから、スキーマが正しく作成されるのかが問題になります。
要するに、難読化されたコードから、スキーマを作成すると、めちゃくちゃなものができる事になります。
この結論にたどり着くまでに、かなり苦戦しました。
苦戦した代わりに、Node.js、Express、NestJS、webpack、Chromeでのデバックなど、いろいろな事を習得する事ができましたが。

さて、type-graphqlを、productionモードでwebpackするときに、注意する点です。

productionモードでwebpackすると、terser-webpack-pluginが有効になります。
これは、コードの圧縮と難読化をするモジュールです。
難読化すると、クラス名も難読化されるため、これが要因でtype-graphqlで作成されるスキーマ(ex schema.gql)が、developmentモードで作成されるものを全く別のものになります。

そこで、クラス名は難読化しないように、webpack.config.jsを構成する必要があります。

terser-webpack-pluginのインストール

terser-webpack-pluginをイントールします。

npm install terser-webpack-plugin --save-dev

webpack.config.jsを構成

webpack.config.jsで、クラス名を変更しないように構成します。
以下のようにするとOKです。

webpack.config.js

const merge = require('webpack-merge');
const common = require('./webpack.common');
const TerserPlugin = require('terser-webpack-plugin');

module.exports = merge(common, {
    mode: 'production',
    optimization: {
        minimizer: [
            new TerserPlugin({
                terserOptions: {
                    keep_classnames: true, // ← ここ！！
                    drop_console: true
                }
            })
        ]
    }
})

これで、クラス名は難読化されなくなるため、コードからGraphQLのスキーマを作成しても、想定通りのものができます。