react-webpack-babel: a React starter that refuses to grow

The pitch is what the starter does not include

react-webpack-babel is a simple React Webpack Babel starter kit, and the README opens by naming the problem it is answering.

Tired of complicated starters with more than 250MB of dependencies which are hard to understand and modify? This is for you. It is a simple react application without redux, stylesheets or other set frameworks. It's only meant to get you started and the rest is up to you. The stated goal is to keep things simple and give you the freedom to select your own frameworks to add on top of this one.

So the design principle is subtraction rather than selection. Most starters try to be a complete opinionated stack so that a newcomer has a working app on the first day, and the cost is that the newcomer cannot tell which part of the build is the framework and which part is the example application. This one starts from the build toolchain and the framework and stops there.

The stated scope is also honest in a way that matters. It is a starting point, not a product, and the author asks in the contribution section that people contribute if they know how to make it better, including the README itself, which is a small signal that the project is not a finished artefact being defended.

The licence is MIT, the primary language is JavaScript, and the repository has no GitHub releases. The last push was on 2026-05-27 and the repository is not archived, so it is maintained but has no versioned release history.

Running it takes clone, install, dev

The setup is deliberately short, and the prerequisites are only git and node.

Clone the project:

git clone https://github.com/ReactJSResources/react-webpack-babel.git

Then install the dependencies:

npm install

And run the development server:

npm run dev

After which you open the web browser to http://localhost:8080/. The dev script is webpack-cli serve with the development mode and the development config file, so the dev server is the Webpack dev server rather than a separate tool.

The other scripts cover the rest of the lifecycle. The test script exports NODE_ENV=test and runs jest. The build script is a chain: it runs clean, then sass, then webpack. The clean script is shx rm -rf build, the sass script compiles src/styles/index.scss into build/index.css with the compressed style option, and the webpack script uses the production config file. There is a separate webpack script that runs only the bundler, and a start script that serves the build directory with serve -s build, which is the static server you would use to check the production bundle locally.

The lint script runs eslint over src and config, and there is an .eslintrc.js config with the React plugin already set up, so linting works on a fresh clone without any configuration.

So a full local cycle is npm install, then npm run dev for development, npm run test for the unit tests, npm run lint for the style check, and npm run build for a production package. That is the whole workflow, and every step is one command.

The dependency set and the versions it froze on

The package.json is where the real state of the template is visible, and it is a mix of current and dated choices.

The build toolchain is modern. Webpack is at ^5.4.0 with webpack-cli at ^4.2.0, and the Babel stack is at 7.12 across @babel/core, @babel/preset-env, @babel/preset-react and @babel/polyfill, with babel-loader 8.2 and babel-plugin-module-resolver 4.0. Sass is at ^1.86.0 with sass-loader 10.0.5, and PostCSS autoprefixer is at 10.0.2. The webpack plugins are html-webpack-plugin 4.5 and copy-webpack-plugin 6.3.

The application side is where the age shows. React and react-dom are pinned at ^17.0.1, and react-router-dom is at ^5.2.0. The test stack is Enzyme 3.11 with enzyme-adapter-react-16 at 1.15.8, which is an adapter for a React version two majors behind the React in the same file. Jest is at ^24.9.0, which is old, and jest is listed among the runtime dependencies rather than the dev dependencies, which is a small packaging oddity that adds weight to the installed tree for anyone who installs with production-only dependencies.

The engines field requires Node 20 or newer, which is the one part of the manifest that is up to date. The version is 0.0.4, and the author field is the ReactJSResources organisation.

So the template has been partly modernised, the Node requirement has moved, and the React and testing stack has not followed. That combination is the main thing to know before you build on it.

How the build is wired, from the config directory

The repository layout explains how the build is organised, and it is a clean separation of concerns that is worth reading as a teaching example.

There is a config/ directory holding the Webpack configuration, and the package.json scripts point at two files in it, config/webpack.config.development.js for the dev server and config/webpack.config.production.js for the build. Splitting development and production into separate files rather than one file with an environment check is a defensible choice, because the two configurations can then differ in ways that a conditional makes murky.

At the top level there is a .babelrc for the Babel configuration, a postcss.config.js for PostCSS, an .eslintrc.js, an .editorconfig, and a __mocks__/ directory. The mocks directory is the Jest convention for module mocking, and its presence alongside enzyme means the test setup can stub things without hitting the network.

The src/ directory holds the application, and the sass script refers to src/styles/index.scss specifically, so the stylesheet entry point is a single file compiled by the build script outside Webpack. That is an unusual arrangement, since normally style-loader and css-loader would handle it inside the bundler, and having both sass-loader and a standalone sass compile in the scripts suggests the standalone path is there for a reason, such as producing a separate stylesheet asset.

The babel-plugin-module-resolver dependency is the other hint about the intended shape. That plugin lets you write imports with a path alias, such as an absolute-looking import from src, rather than relative paths climbing out of a component folder. In a starter meant to be extended, that alias is what keeps imports readable once the tree grows.

There is a .circleci/ directory for continuous integration, a CODE_OF_CONDUCT.md and a CODEOWNERS file, and a package-lock.json, so the dependency versions are pinned and the project has a defined review and CI story.

Where this starter is the wrong choice in 2026

The first problem is React 17. The template pins react and react-dom at ^17.0.1, and React 17 is several majors behind current React. A team picking this up today would be starting on a version whose rendering model, StrictMode behaviour and ecosystem support differ from what most documentation and tutorials describe, and the first thing most teams would do is upgrade the version, at which point the Enzyme adapter for React 16 has to be replaced too.

The second is the test stack. Enzyme with the React 16 adapter and Jest 24 is a combination that belongs to a specific period, and Enzyme has largely been superseded by the React Testing Library approach. The presence of an adapter for React 16 alongside React 17 in the same file is a visible symptom of a template that has been partly updated rather than rebuilt.

The third is that the premise has aged. When this starter was written, the choice was between a heavyweight preset that made decisions for you and nothing. The current middle ground is a modern bundler with sensible defaults, where a new project is created by a create command and the build configuration is a file you edit rather than a file you write. A template that omits the modern conveniences can end up costing more work than it saves, because you are reimplementing what a current tool gives you free.

The fourth is the dependency weight claim, which is relative. The starter's argument against 250MB starters is about comprehensibility, and it is still a fair argument, but the packages it does include, particularly the older Jest and the Enzyme stack, are themselves not small.

What the project is genuinely good for remains unchanged: reading. If you want to understand how Webpack, Babel, Sass and PostCSS fit together in a React application without a framework's abstractions in the way, this repository shows the whole pipeline in a few hundred lines that you can read in an afternoon.

Editorial conclusion

react-webpack-babel is a good pick for a developer who wants to see a plain Webpack and Babel React build without a framework's opinions layered on, because the project explicitly refuses to bring redux, a stylesheet framework or a preset toolchain, so you can read every moving part; it is the wrong starting point for a new production app, because the React and Enzyme versions it pins are several majors behind and the tooling would need updating before you wrote a line of your own, so before you build on it you should check the React version in package.json against what you intend to use.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. ReactJSResources/react-webpack-babel on GitHub
4. README