冗長なので書き直し。
webpack は バンドラ、トランスパイラ と呼ばれるツール。 npm 等のモジュール管理ツールでインストールした js モジュール群を単一ファイル、或いは複数ファイルにまとめたり、 TypeScript 等の AltJS をトランスパイル（変換）する。
類似ツールとして Grunt、 gulp.js が存在する。こちらは タスクランナー と呼ばれたり(する|した)。
Node.js で動作する。 npm は Node.js で動作するモジュール（パッケージ）管理ツール。
webpack 自体も npm でインストールする。
バンドルについては主の js ファイルから require や import で読み込むことで webpack で適宜バンドルされる。
また、読み込み時にインラインで記載したパラメータ（QueryString?）や webpack.config 等の設定ファイルの内容に基づいて各種 loader 経由でトランスパイルされる。
npm-scripts に記載する事でもある程度対応できるが、ファイル読み込み時に逐次記載する手間や全体の見通しが悪くなる事を考慮すると webpack.config を作成する事が望ましい。
上記記載の通り webpack.config を作成する。また、 webpack コマンドについてはオプション等もある事から npm-scripts の使う。
環境については webpack-merge を利用した設定ファイル自体を分ける方法、 webpack の env を利用して設定ファイル内で変更する方法がある。ケースバイケースで対応する。
Environment Variables | webpack
トランスパイルする対象のファイル名 + loader で大体見つかる。類似のものがある場合や長期間メンテナンスされていないものもあるため注意。
webpack の機能を拡張するもの。
あたりは使用するケースが多い。
バージョンが変わると config ファイルの記述方法が変わる事がある。また、各 loader が動作しなくなることもあるため、（ webpack に限った話ではないが）バージョンアップには十分注意すること。
Node.js のバージョンアップで動作しなくなる場合がある。 npm rebuild 、あるいは
npm cache clean --force
rm -rf node_modules
npm iで大体直る。直らなかった場合、 nodenv 等のバージョンマネージャも検討。
基本はトランスパイル機能を目的に使用する。 webpack でバンドルした各ライブラリはグローバルからの参照が（未設定では）できないため、 JavaScript での実装に重きを置かないWeb制作等の場合は周知のコストやイレギュラー対応の方が高くつく可能性がある。
js や css ( PostCSS、 Sass 等) のトランスパイルに留めるのであれば大きく問題にはならない。
静的サイトの出力（テンプレートファイルから HTMLの出力） は gulp に分がある気がする。 publicPath の概念が分かりづらい。 webpack で無理矢理独自の生成タスクを作るくらいなら、要件が許せば最初から Static site generator の導入や JAMstack にするのも手。その場合、置き場所（webサーバ）はそこまで選ばないが、開発環境や学習コストには配慮すること。