This is a CRA fork that I use for my projects. You can use it, too.
However, I strongly recommend using the official CRA and contributing to help improve the official CRA.
Add some SAUCEsomeness to your CRAwesomeness, supporting:
- Monorepos -- transpile other packages in your monorepo
- App variants -- react native -like source file overrides by extension, e.g. MyComponent.ios.js, but configurable
See Additional Features for more info.
It's a much better idea to use the official CRA unless you are extremely adventurous or desperate.
- Trail official CRA releases
- Add useful features that aren't yet supported by official CRA
- Transition to official CRA features as they become available
- Die when official CRA supports all features
yarn remove react-scripts, thenyarn add @bradfordlemley/react-scripts --exact@bradfordlemley/react-scriptsuses the same versioning asreact-scripts, except that the patch version is x100, e.g.,@bradfordlemley/react-scripts@2.0.401is based onreact-scripts@2.0.4(This allows several versions based on a singlereact-scriptsrelease, but means@bradfordlemley\react-scriptsitself is not semantically versioned so you should pin the exact version.)
- With "monorepo support", other packages in the monorepo can be treated as app sources -- watched, linted, transpiled, and tested in the same way as if they were part of the app itself.
- This allows you to share components between multiple apps in the monorepo, and also allows the components to be truly modular with their own dependencies, etc.
- You can share components in a monorepo without integrated "monorepo support" -- each package needs its own build/test/etc scripts. The scripts need to be orchestrated to allow everything to be developed in parallel and the result can be a cumbersome development experience compared to integrated "monorepo support".
- "monorepo support" was included in some CRA 2 alpha releases, but was reverted for the official CRA 2.0 release. CRA is currently recommending using nwb to support component packages in the monorepo.
A typical monorepo folder structure looks like this:
monorepo/
apps/
app1/ ... import Comp1 from 'comp1'
app2/ ... import Comp1 from 'comp1'
comps/
comp1/
...
Below expands on the monorepo structure above, adding the package.json files required to configure the monorepo for yarn workspaces.
monorepo/
package.json:
"workspaces": ["apps/*", "comps/*"],
"private": true
apps/
app1/
package.json:
"dependencies": {
"@myorg/comp1": ">=0.0.0",
"react": "^16.2.0"
},
"devDependencies": {
"@bradfordlemley/react-scripts": "2.0.402"
},
"sourceWorkspaces" : [
"comps/*"
]
src/
app.js: import Comp1 from '@myorg/comp1';
app2/
package.json:
"dependencies": {
"@myorg/comp1": ">=0.0.0",
"@myorg/tscomp1": ">=0.0.0",
"react": "^16.2.0"
},
"devDependencies": {
"@bradfordlemley/react-scripts": "2.0.402"
},
"sourceWorkspaces" : [
"comps/*"
]
tsconfig.json:
"include": [
"src",
"../../comps/**/*"
]
src/
app.js: import Comp1 from '@myorg/comp1';
comps/
comp1/
package.json:
"name": "@myorg/comp1",
"version": "0.1.0"
index.js
comp2/
package.json:
"name": "@myorg/comp2",
"version": "0.1.0",
"dependencies": ["@myorg/comp1": ">=0.0.0"],
"devDependencies": ["react": "^16.2.0"]
index.js: import Comp1 from '@myorg/comp1';
tscomp1/
package.json:
"name": "@myorg/tscomp1",
"version": "0.1.0",
"devDependencies": ["react": "^16.2.0"]
index.tsx: ...
- The "workspaces" entry in the top-level package.json is an array of glob patterns specifying where shared packages are located in the monorepo.
- The "sourceWorkspaces" entry in an app's package.json is array of glob patterns similar to "workspaces", but specifying which packages in the monorepo should be treated as source.
- The scoping prefixes, e.g. @myorg/, are not required, but are recommended, allowing you to differentiate your packages from others of the same name. See scoped packages for more info.
- Using a package in the monorepo is accomplished in the same manner as a published npm package, by specifying the shared package as dependency.
- In order to pick up the monorepo version of a package, the specified dependency version must semantically match the package version in the monorepo. See semver for info on semantic version matching.
For typescript components, the shared components' paths must be included via tsconfig.json's include, see example above.
Type error: Could not find a declaration file for module ... TS7016 is the error that indicates shared components are not properly included in tsconfig.json.
Lerna is a popular tool for managing monorepos. Lerna can be configured to use yarn workspaces, so it will work with the monorepo structure above. It's important to note that while lerna helps publish various packages in a monorepo, react-scripts does nothing to help publish a component to npm. A component which uses JSX or ES6+ features would need to be built by another tool before it can be published to npm. See publishing components to npm for more info.
This feature can be used for producing slight differences in an app, e.g. to support an admin variant of the app or a hybrid version of the app.
app/
package.json:
"devDependencies": {
"@bradfordlemley/react-scripts": "2.0.402"
},
"targets": {
"ios": { <-- configure ios variant
"jsExts": [
".ios.js",
".cor.js"
],
"appHtml": "index.cor.html"
},
"android": { <-- configure android variant
"jsExts": [
".android.js",
".cor.js"
],
"appHtml": "index.cor.html"
},
},
"scripts": {
"build": "react-scripts build", // standard build
"build:android": "TARGET=android react-scripts build", // build android
"build:ios": "TARGET=ios react-scripts build" // build ios
}
src/
App.js
import comp1 from './comp1';
import comp2 from './comp2';
comp1.js // standard build
comp1.android.js // used for TARGET=android build
comp1.ios.js // used for TARGET=ios build
comp2.js // used for standard build
comp2.cor.js // used for both ios and android builds
public/
index.html // standard build
index.cor.html // used for both ios and android builds
build/ // build output for standard build
build_android/ // build output for TARGET=android
build_ios/ // build output for TARGET=ios
Create React apps with no build configuration.
- Creating an App – How to create a new app.
- User Guide – How to develop apps bootstrapped with Create React App.
Create React App works on macOS, Windows, and Linux.
If something doesn’t work, please file an issue.
npx create-react-app my-app
cd my-app
npm start(npx comes with npm 5.2+ and higher, see instructions for older npm versions)
Then open http://localhost:3000/ to see your app.
When you’re ready to deploy to production, create a minified bundle with npm run build.
You don’t need to install or configure tools like Webpack or Babel.
They are preconfigured and hidden so that you can focus on the code.
Just create a project, and you’re good to go.
You’ll need to have Node 8.10.0 or later on your local development machine (but it’s not required on the server). You can use nvm (macOS/Linux) or nvm-windows to easily switch Node versions between different projects.
To create a new app, you may choose one of the following methods:
npx create-react-app my-app(npx comes with npm 5.2+ and higher, see instructions for older npm versions)
npm init react-app my-appnpm init <initializer> is available in npm 6+
yarn create react-app my-appyarn create is available in Yarn 0.25+
It will create a directory called my-app inside the current folder.
Inside that directory, it will generate the initial project structure and install the transitive dependencies:
my-app
├── README.md
├── node_modules
├── package.json
├── .gitignore
├── public
│ ├── favicon.ico
│ ├── index.html
│ └── manifest.json
└── src
├── App.css
├── App.js
├── App.test.js
├── index.css
├── index.js
├── logo.svg
└── serviceWorker.js
No configuration or complicated folder structures, just the files you need to build your app.
Once the installation is done, you can open your project folder:
cd my-appInside the newly created project, you can run some built-in commands:
Runs the app in development mode.
Open http://localhost:3000 to view it in the browser.
The page will automatically reload if you make changes to the code.
You will see the build errors and lint warnings in the console.
Runs the test watcher in an interactive mode.
By default, runs tests related to files changed since the last commit.
Builds the app for production to the build folder.
It correctly bundles React in production mode and optimizes the build for the best performance.
The build is minified and the filenames include the hashes.
Your app is ready to be deployed.
You can find detailed instructions on using Create React App and many tips in its documentation.
Please refer to the User Guide for this and other information.
-
One Dependency: There is just one build dependency. It uses Webpack, Babel, ESLint, and other amazing projects, but provides a cohesive curated experience on top of them.
-
No Configuration Required: You don't need to configure anything. Reasonably good configuration of both development and production builds is handled for you so you can focus on writing code.
-
No Lock-In: You can “eject” to a custom setup at any time. Run a single command, and all the configuration and build dependencies will be moved directly into your project, so you can pick up right where you left off.
Your environment will have everything you need to build a modern single-page React app:
- React, JSX, ES6, TypeScript and Flow syntax support.
- Language extras beyond ES6 like the object spread operator.
- Autoprefixed CSS, so you don’t need
-webkit-or other prefixes. - A fast interactive unit test runner with built-in support for coverage reporting.
- A live development server that warns about common mistakes.
- A build script to bundle JS, CSS, and images for production, with hashes and sourcemaps.
- An offline-first service worker and a web app manifest, meeting all the Progressive Web App criteria. (Note: Using the service worker is opt-in as of
react-scripts@2.0.0and higher) - Hassle-free updates for the above tools with a single dependency.
Check out this guide for an overview of how these tools fit together.
The tradeoff is that these tools are preconfigured to work in a specific way. If your project needs more customization, you can "eject" and customize it, but then you will need to maintain this configuration.
Create React App is a great fit for:
- Learning React in a comfortable and feature-rich development environment.
- Starting new single-page React applications.
- Creating examples with React for your libraries and components.
Here’s a few common cases where you might want to try something else:
-
If you want to try React without hundreds of transitive build tool dependencies, consider using a single HTML file or an online sandbox instead.
-
If you need to integrate React code with a server-side template framework like Rails or Django, or if you’re not building a single-page app, consider using nwb, or Neutrino which are more flexible. For Rails specifically, you can use Rails Webpacker.
-
If you need to publish a React component, nwb can also do this, as well as Neutrino's react-components preset.
-
If you want to do server rendering with React and Node.js, check out Next.js or Razzle. Create React App is agnostic of the backend, and just produces static HTML/JS/CSS bundles.
-
If your website is mostly static (for example, a portfolio or a blog), consider using Gatsby instead. Unlike Create React App, it pre-renders the website into HTML at the build time.
-
Finally, if you need more customization, check out Neutrino and its React preset.
All of the above tools can work with little to no configuration.
If you prefer configuring the build yourself, follow this guide.
We'd love to have your helping hand on create-react-app! See CONTRIBUTING.md for more information on what we're looking for and how to get started.
Looking for something similar, but for React Native?
Check out Create React Native App.
We are grateful to the authors of existing related projects for their ideas and collaboration:
Create React App is open source software licensed as MIT.