# The boilerplate ships a directory called __DELELE_ME__ and a test command that passes with no tests

> react-native-boilerplate is an Expo and React Native starter with routing, state, theming, environment handling and deployment scripts already wired. Its documentation is unusually specific and mostly trustworthy, but a few artefacts shipped that should not have: a placeholder directory at the root, a test flag that hides an empty suite, and an environment-verification command that prints the public config it warns against.

**wataru-maeda/react-native-boilerplate** —  Production-ready React Native boilerplate for iOS, Android,   and Web with Expo SDK 54, React 19.1, Expo Router v6, Redux   Toolkit, TypeScript, and AI-optimized development   (Claude/Cursor). Features modern architecture, static web   rendering, and automated deployment workflows.

- Repository: https://github.com/wataru-maeda/react-native-boilerplate
- Stars: 517 · Forks: 137
- Language: TypeScript
- License: MIT
- Published: 2026-09-15 · Updated: 2026-09-15 · Language: en
- Canonical page: https://hysenlabs.com/projects/wataru-maeda-react-native-boilerplate

## A placeholder directory named __DELELE_ME__ is committed

The top level of the repository contains a directory whose name is a misspelling of a phrase meaning delete me. It sits between the readme and the application source, alongside the expected folders for screens, components, hooks, providers, services, state slices, theming, types and utilities. Two assistant-specific folders are also committed, one for Claude and one for Cursor, together with a matching instruction file at the root, which is how the template backs its claim of being set up for AI-assisted development. The rest of the layout is disciplined: a lint and formatter configuration with ignore files, a Git hooks directory with a staged-linting configuration, editor settings, a Metro config, a Jest config, a build configuration file and a typed configuration file. Which makes the placeholder stand out. A directory that exists to be deleted before you start is fine in a template, and shipping it inside the template is not.

## The test command passes with zero tests

Testing is listed among the pre-configured features, with a React Native Testing Library setup and a Jest configuration file in the repository. The script itself is what tells you how seriously to take it:

```
"test": "jest --verbose --passWithNoTests"
```

That flag tells Jest to exit successfully when it finds no test files at all. In a boilerplate that is arguably the right default, since a fresh clone should not have a red build. It is also a flag that a continuous integration job inherits silently, so a project can ship for months with the pipeline green and nothing executed. The same pattern shows up in the other two test scripts, including the watch variant. If you take this template, the first commit you make should add one real test, because the difference between a configured harness and a working one is exactly the thing that flag removes.

## The documented way to check variables prints the public config

The environment handling is the most thoughtful part of the template and also the part with a contradiction worth reading twice. Values live in separate development and production files, are declared in the app config under an extra object, and are read through a small config utility. The setup instructions say to add a new variable to both environment files, add it to the app config, and define it in the utility, which is four edits across four files for one value. Then there is the security section, which says the project deliberately avoids the public environment variable prefix because anything so named is exposed to clients, and points at the platform's own guidance on storing sensitive values. And in between, the verification step says to run the config command for the public type. Those two instructions pull in opposite directions: the place the documentation tells you to put variables is the place it also tells you is client-visible, and the command it offers for checking your work is the one that prints the public view of it.

## Building mobile pushes secrets to the build service first

The secret handling is otherwise sensible. Values are uploaded to the hosted build service as secrets, accessible only during build and submit, with a dedicated command that pushes the development and production files, and a companion command that lists the environment. Every development script in the manifest wraps its command in the same way: it disables the framework's own dotenv handling and substitutes a separate tool, which is a deliberate choice to have one variable loader rather than two. The mobile build script is where the interesting coupling sits. It does not simply build; it runs the secret push first and then invokes the hosted build tool with the development profile, so building a mobile binary on your machine uploads your development secrets to the service every time you run it, with a force flag. That is convenient and it is also a surprise waiting for someone who has not internalised what the script does.

## The distribution command builds the development profile

The distribution section says one command generates an iOS package and an Android package, and another deploys the web build to the hosted platform. The scripts say something narrower. The mobile build script invokes the hosted build tool with the development profile, which is what produces a development client build rather than a store distribution, and the web path is a local export followed by a deploy to a development environment. No release-profile script appears in the visible list of scripts, which is consistent with the templates philosophy of only including the most commonly used pieces and inconsistent with a documentation line promising packages. None of this is dangerous, but it is the sort of gap that costs an afternoon on a first release, and it is a reminder that in a boilerplate the prose and the manifest can drift apart without anything failing.

## npm or yarn, but only the npm lockfile ships

The quick start offers both package managers, telling you to install with either npm or yarn and to start the development environment with either one. The repository ships an npm lockfile and no yarn lockfile, and the scripts assume a shell that understands the environment wrapper the npm scripts use. Installing with yarn will therefore resolve different dependency versions from the ones the template was built against, without any warning, since the missing yarn lockfile means yarn will generate its own from the ranges in the manifest. The manifest itself is marked private, so this is not a package anyone installs from a registry, despite how often boilerplate projects turn up in package searches. Its entry point is the router package rather than a local file, which is the convention that makes file-based routing work, and its dependencies pin some things exactly while floating others with ranges, including the bottom sheet and the navigation packages.

## The routing guide is a diagram, and the rest is line-number links

Navigation is the one part documented as a diagram rather than prose, showing a drawer root with two tabs, each holding a stack with a screen and a details screen:

```
Root (Drawer)
├── Home Tab
│   └── Stack
│       ├── Home Screen
│       └── Details Screen
└── Profile Tab
    └── Stack
        ├── Profile Screen
        └── Details Screen
```

That shape means two separate detail routes rather than one shared one, which is the usual consequence of putting a stack inside each tab. The rest of the documentation uses a different technique, and it is the part most likely to rot: instructions point at specific files and, in several cases, at specific line numbers inside them, telling you where the usage examples are and which line to remove to disable the state logger. Those anchors are exact today and meaningless after the next reformat, and nothing in continuous integration checks them. The same applies to the setup steps, which tell you to edit a particular property in a particular configuration file at a particular line. For a template meant to be forked and lived in, path-level instructions survive; line-level ones do not.

## Conclusion

This is a good starter to copy rather than a product to adopt, and the setup work it saves is real: routing, theming, state, environment plumbing and deployment scripts are all done. Three things to check before you build on it. The environment flow asks you to put values into the app config while a separate section warns that anything in the public config reaches clients, so decide where secrets live before you add any, and do not rely on the documented verification command as a safety check. The test command passes with zero tests, so wire up coverage or a failing test in continuous integration or the suite will stay green and empty. And the root contains a leftover placeholder directory that is a typo of its own name, which is a good indicator of how the template was assembled.

## FAQ

### What does the react-native-boilerplate template include?

Expo SDK 54 with React 19.1 and React Native 0.81.4 and the new architecture enabled, Expo Router v6 with drawer and tab file-based routing, Redux Toolkit with example slices, light and dark theming with a colour-scheme hook, dotenvx-managed development and production environments, hosted build and deploy scripts, ESLint 9, Prettier, Jest with the React Native Testing Library, and Claude and Cursor instruction files.

### What do I need to run react-native-boilerplate?

Node 20 or newer, the Expo CLI, and the EAS CLI if you intend to build or deploy. Then install the packages and run the development script, either for all platforms at once or for iOS, Android or web individually. The repository ships an npm lockfile and no yarn lockfile.

### How does react-native-boilerplate handle environment variables?

With dotenvx across separate development and production files, with values declared in the app configuration and read through a config utility, and uploaded to the hosted build service as secrets rather than exposed with the public prefix. A documented alternative uses the public prefix for non-sensitive values only, with an explicit warning that anything so named reaches clients.

### Does react-native-boilerplate come with tests?

The testing library setup and a Jest configuration are included, but the test script runs with the flag that passes when no tests are found. So a green run means the harness works rather than that anything is covered, and you should add a real test before trusting a pipeline built on it.

## Sources

- [Issues](https://github.com/wataru-maeda/react-native-boilerplate/issues)
- [License: MIT](https://github.com/wataru-maeda/react-native-boilerplate/blob/main/LICENSE)
- [README](https://github.com/wataru-maeda/react-native-boilerplate/blob/main/README.md)
- [Releases](https://github.com/wataru-maeda/react-native-boilerplate/releases)
- [wataru-maeda/react-native-boilerplate on GitHub](https://github.com/wataru-maeda/react-native-boilerplate)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wataru-maeda-react-native-boilerplate