Phaser Webpack template: the build already wired up

What you get out of the box

This is a Phaser 3 project template that uses Webpack for bundling, and it supports hot reloading for a quick development workflow and includes scripts to generate production-ready builds.

The scope is narrow and that is the point. There is no build configuration to write, no asset pipeline to design and no decision about module format. The template is a decision about tooling that has already been made, in exchange for a project structure you can change on the first day.

The README states which versions the template was updated for, Phaser 3.90.0 and Webpack 5.99.6, and the package metadata carries a matching Webpack dependency at ^5.99.6. There is also a TypeScript version of the same template, linked from the README, for teams who would rather not write JavaScript.

The requirement list is short: Node.js is required to install dependencies and run the scripts via npm. That is the whole toolchain requirement, which is another way of saying the template trades a little flexibility for a very small setup cost.

Five commands, two of them for people who want no network calls

The available commands table is the interface of the template:

| Command | Description | |---------|-------------| | `npm install` | Install project dependencies | | `npm run dev` | Launch a development web server | | `npm run build` | Create a production build in the `dist` folder | | `npm run dev-nolog` | Launch a development web server without sending anonymous data | | `npm run build-nolog` | Create a production build without sending anonymous data |

The dev and build scripts are the ones you will type constantly. The dev script runs webpack-dev-server with the development config and opens a browser, and the local development server runs on http://localhost:8080 by default. The README points at the webpack documentation for changing that or adding SSL support.

The two nolog variants are the same commands with the usage report removed, and they are worth knowing about before your first build rather than after it.

The development loop is the standard hot reloading one. After npm install, npm run dev starts the server, you edit any file in the src folder, webpack recompiles and reloads the browser. That is a large part of what a template is for, since the difference between a working hot reload and a broken one is a few hours of configuration.

The project structure, in seven paths

The template provides a default structure so you do not have to invent one, and the README lists it in full.

The public/ directory holds the static shell of the page. public/index.html is a basic HTML page to contain the game, public/style.css holds the global layout styles, and public/assets holds game sprites and audio, served directly at runtime.

The src/ directory holds the code. src/main.js is the application bootstrap, src/game is the folder containing the game code, src/game/main.js is the game entry point that configures and starts the game, and src/game/scenes is the folder with all the Phaser game scenes.

The separation is worth noting because it is the decision most templates get wrong. Assets that ship with the game live in public and are addressed by URL, while code is bundled. A scene folder under src/game/scenes is the Phaser convention, and the entry point is separate from the bootstrap, which leaves room for a build that does more than start a game.

The top-level layout matches that: index.html, a webpack/ directory holding the build configuration, a src/ directory, public/, a log.js file, a .babelrc for the browser targets, and a package.json with the scripts.

Two ways to load an asset, and they end up in different places

Webpack supports loading assets through JavaScript module import statements, and the template supports both embedding assets and loading them from a static folder.

To embed an asset you import it at the top of the file you use it in:

import logoImg from './assets/logo.png'

To load static files such as audio or video, you place them in the public/assets folder and then reference that path in the Loader calls within Phaser:

preload ()
{
    //  This is an example of an imported bundled image.
    //  Remember to import it at the top of this file
    this.load.image('logo', logoImg);

    //  This is an example of loading a static image
    //  from the public/assets folder:
    this.load.image('background', 'assets/bg.png');
}

The difference matters at build time. When you issue the npm run build command, all static assets are automatically copied to the dist/assets folder, so the public/ path survives into the build, while imported assets are hashed into the bundle by webpack.

Deployment is then trivial to state. After npm run build, your code is built into a single bundle and saved into the dist folder, along with any other assets your project imported or stored in the public assets folder, and to deploy the game you upload all of the contents of the dist folder to a public facing web server. No server-side rendering, no special host, just files.

Babel targets and where to change the build

You can write modern ES6+ JavaScript and Babel will transpile it to a version of JavaScript that your project needs to support. The targeted browsers are set in the .babelrc file, and the default currently targets all browsers with total usage over 0.25 percent, but excludes IE11 and Opera Mini:

"browsers": [
  ">0.25%",
  "not ie 11",
  "not op_mini all"
]

The two build configuration files are separate on purpose. The development config is webpack/config.js and the production one is webpack/config.prod.js, and the npm scripts point at each respectively.

If you want to customise the build, such as adding a new webpack loader or plugin, for loading CSS or fonts, the README tells you to modify the webpack/config.js file for cross-project changes, or to modify and create new configuration files and target them in specific npm tasks inside package.json. That split between the shared config and the task-specific ones is the mechanism that lets the template be forked and customised without the customisations being lost on the next pull, and it is a good reason to look at the webpack directory before you start.

The dependency list explains the rest of the structure: clean-webpack-plugin and copy-webpack-plugin for the output directory, html-webpack-plugin for the page, terser-webpack-plugin for minification, file-loader and raw-loader for assets, webpack-merge to combine configurations, and webpack-dev-server for the development loop.

The usage report, and the two ways to switch it off

The most unusual part of the template is a file called log.js, and the README explains it in unusual detail, which is to its credit.

If you inspect the node scripts you will find a file called log.js, and it makes a single silent API call to a domain called gryzor.co, owned by Phaser Studio Inc, with the domain name described as a homage to one of the author's favourite retro games.

Three pieces of data are sent: the name of the template being used, such as vue or react, whether the build was dev or prod, and the version of Phaser being used. The README states that at no point is any personal data collected or sent, that they do not know about your project files, your device, your browser or anything else, and invites you to inspect the log.js file to confirm it.

The reason given is a good one. Because the project is open source, there are no visible metrics about which templates are being used, and since the maintainers work hard to maintain a large and diverse set of templates, this is their small anonymous way to find out whether that work pays off.

If you would rather not send anything, there are two routes. The command variants:

npm run dev-nolog

and npm run build-nolog for a build, or you can disable the log entirely by deleting the log.js file and removing the call to it in the scripts section of package.json, changing the two script entries from node log.js dev & dev-template-script to just dev-template-script, and the same for build. The README asks, in that case, that you at least join the Discord or send an email to say which template you are using.

Where the Phaser Webpack template is the wrong choice

The first wrong-tool case is a project that already has a build. A template is most valuable at the start of a project and least valuable in the middle of one, because by then the build configuration is the part of the repository you understand best and are most unwilling to replace. For a team with an existing webpack setup, or a preference for Vite or esbuild, the template's value drops to the directory layout, which is a small thing to copy.

The second is a project that wants the newest Phaser. The README says the template was updated for Phaser 3.90.0, while the package metadata pins the phaser dependency at 4.0.0, and the description still calls it a Phaser 3 project template. That mismatch is exactly the kind of thing a template inherits, and a team that wants to move to Phaser 4 will be doing the integration work themselves.

The third is a deployment that must not make network calls during a build. The default dev and build scripts both call out to a domain, and while the nolog variants exist, a team that forgets them will have a build that fails in an air-gapped environment or that phones home from a CI runner. The fix is trivial once you know it, and annoying if you discover it from a failed pipeline.

The last point is scope. This template is a bundler setup and nothing else. It has no asset optimisation beyond what webpack gives you, no testing story, no deployment configuration, and no TypeScript unless you take the separate template. For a project that needs those, the template is a starting point rather than a solution.

MIT, a single release tag and a template that is still maintained

The template is MIT licensed, with the LICENSE file at the repository root, and the package metadata names the author as Phaser Studio with a support address.

The release history is thin, with a single tag, v2.0.0 from 2023-10-24, and the package version in package.json is 3.3.0, so the npm version and the git tag do not line up, which is normal for a template that is used by cloning rather than by installing a version.

The repository is not archived, and the last push was on 2026-04-10, so the template is still being touched even though it has not been tagged recently. The top-level listing is a good description of a project template: .babelrc, index.html, log.js, package-lock.json, package.json, public/, a screenshot, src/, webpack/ and the licence.

The public face of the project is its sibling templates and the community around them. The README closes by pointing at the Phaser website, the Phaser social account, the made with Phaser search, the API documentation and the support forum, and the TypeScript variant is linked from the top. What you are adopting, in other words, is one cell in a family of official starting points, and its value is that the boring parts are already consistent with the other templates in that family.

Editorial conclusion

Adopt this template if you are starting a Phaser project with Webpack and want a working dev loop and production build without assembling the configuration first, and use the -nolog variants from the start if a network call during the build is not acceptable in your environment. Do not adopt it if you are starting a greenfield project and would rather pick your own bundler, since the value is precisely the configuration that is already there, and do not copy the template into a project without reading the log.js section, because the build script makes a network call by default. Before you build, check which Phaser version the package actually pins, since the README and the dependency do not agree.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. phaserjs/template-webpack on GitHub
4. README
5. Releases