如何開發由Create-React-App 引導的應用（三）

時間 2019-11-30

標籤如何開發 create react app 引導應用欄目 React 简体版

原文原文鏈接

此文章是翻譯How to develop apps bootstrapped with Create React App 官方文檔html

系列文章

如何開發由Create-React-App 引導的應用
如何開發由Create-React-App 引導的應用（一）
如何開發由Create-React-App 引導的應用（二）
如何開發由Create-React-App 引導的應用（四）

Integrating with an API Backend

這些教程將幫助您將應用程序與在另外一個端口上運行的API後端集成，使用fetch()來訪問它。前端

Node

看看這個教程。您能夠在這裏找到配套的GitHub存儲庫。node

Ruby on Rails

看看這個教程。您能夠在這裏找到配套的GitHub存儲庫。react

Proxying API Requests in Development

注意：這個特性須要react-scripts@0.2.3 版本以上。git

人們經過提供與前端React 應用相同的主機和端口做爲後端實現。
例如，應用部署後，生產設置可能看上去像這樣：github

/             - static server returns index.html with React app
/todos        - static server returns index.html with React app
/api/todos    - server handles any `/api/*` requests using the backend implementation

像這樣的設置不是必須的。可是，若是你已經有了一個這樣的設置，很方便寫fetch('api/todos') 這樣的請求而沒必要擔憂在開發過程當中將它們重定向到另外一個主機或端口。web

在開發中，讓開發服務器代理任何未知API 服務請求，添加一個proxy 域到你的package.json，例如：express

"proxy": "http://localhost:4000"

這樣，當您在開發中fetch('/api/todos')時，開發服務器將會認識到它不是一個靜態資產，並會將您的請求代理到http://localhost:4000/api/todos做爲後備。開發服務器將僅嘗試發送沒有text/html accept header 的請求到代理。npm

方便的，這樣能夠避免在開發過程當中發生CORS問題和像下面的錯誤消息：編程

Fetch API cannot load http://localhost:4000/api/todos. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

請記住，proxy僅在開發中有效（使用npm start），由你確保像/api/todos 這樣的URL指向正確的生產環境。你沒必要使用/api 前綴。任何沒法識別沒有text/html accept header 的請求，將被重定向到指定的proxy。

proxy 選項支持HTTP，HTTPS和WebSocket鏈接。
若是proxy 選項對你不夠靈活，或者你能夠：

在您的服務器上啓用CORS（這是在Express 中的操做方法）。
使用環境變量將正確的服務器主機和端口注入到應用程序中。

Using HTTPS in Development

注意：這個特性須要react-scripts@0.4.0 版本以上。

您可能須要開發服務器經過HTTPS提供頁面。一個特別的狀況多是有用的，當API服務器自己服務自己用於HTTPS時，使用the "proxy" feature來代理對API服務器的請求。

爲此，請將HTTPS 環境變量設置爲true，而後像以往那樣以npm start啓動開發服務器：

Windows(cmd.exe)

set HTTPS=true&&npm start

（注意：空格的缺失是有意的）

Linux, macOS(Bash)

HTTPS=true npm start

請注意，服務器將使用自簽名證書，所以你的Web瀏覽器幾乎確定會在訪問頁面時顯示警告。

Generating Dynamic `<meta>` Tags on the Server

因爲Create React App 不支持服務器渲染，你可能想知道如何使<meta>標籤動態化並反映當前URL。爲了解決這個問題，咱們建議在HTML中添加佔位符，以下所示：

<!doctype html>
<html lang="en">
  <head>
    <meta property="og:title" content="__OG_TITLE__">
    <meta property="og:description" content="__OG_DESCRIPTION__">`

而後，在服務器上，無論你使用的後端，你均可以將index.html讀入內存，並根據當前URL替換__OG_TITLE__、__OG_DESCRIPTION__以及任何其餘具備值的佔位符。只需確保清理和轉義內插的值，以便它們能夠安全地嵌入到HTML中！

若是使用Node服務器，你甚至能夠在客戶端和服務器之間共享路由匹配邏輯。可是在簡單的狀況下，複製它也能夠正常工做。

Pre-Rendering into Static HTML Files

若是您使用靜態主機提供商託管您的構建程序，則可使用反應快照爲應用程序中的每一個路由或相對連接生成HTML頁面。而後，這些頁面將在JavaScript軟件包加載時無縫地變爲活動狀態或「水合」。

還有機會在靜態託管以外使用它，在生成和緩存路由時將壓力從服務器上取下。

預渲染的主要優勢是，你可使用HTML有效內容獲取每一個頁面的核心內容，而無論你的JavaScript軟件包是否成功下載。這也增長了你的應用程序的每一個路由將被搜索引擎抓取的可能性。

你能夠閱讀零配置預渲染（也成爲snapshotting）。

Injecting Data from the Server into the Page

同上一節類似，你能夠在HTML 中留一些插入全局變量的佔位符，例如：

<!document html>
<html lang="en">
  <head>
    <script>
      window.SERVER_DATA = __SERVER_DATA__
    </script>

而後，在服務器上，您能夠在發送響應以前將__SERVER_DATA__替換爲真實的JSON數據。客戶端代碼能夠讀取window.SERVER_DATA來使用它。 確保在清理JSON以後再發送到客戶端，由於它使你的應用程序易受XSS攻擊。

Running Test

注意：這個特性須要react-scripts@0.3.0 版本以上。
閱讀遷移指導若是在舊項目中使用

Create React App 使用Jest做爲其測試運行器。爲了作好這個整合的準備，咱們爲Jest作了一個重大變革，因此若是你聽到不少年前的壞事，請再試一次。

Jest是一個基於Node的運行器。這意味着測試老是在Node環境中運行，而不是在真實的瀏覽器中運行。這使咱們可以實現加快迭代速度並防止怪異的行爲。

雖然Jest提供像window的瀏覽器全局變量，這多虧了jsdom，但它們只是同真正的瀏覽器行爲類似。 Jest旨在用於你的邏輯和組件的單元測試，而不是DOM怪異。

若是須要，咱們建議你使用單獨的瀏覽器端到端的測試工具。它們超出了Create React App的範圍。

Filename Coventions

Jest將使用如下任何常見的命名規則來查找測試文件：

__tests__文件夾中帶有.js後綴的文件。
帶有.test.js後綴的文件。
帶有.spec.js後綴的文件。

.test.js 或.spec.js 文件（或__tests__文件夾）能夠位於src頂級文件夾下的任意深度。

咱們建議將測試文件（或__tests__文件夾）放在正在測試的代碼旁邊，以使相對導入路徑更短。例如，若是App.test.js和App.js在同一個文件夾中，測試只須要從import App from './App'，而不是長的相對路徑。 Colocation還有助於在更大的項目中更快地找到測試。

Command Line Interface

當你運行npm test時，Jest將以觀察者模式啓動。每次保存文件時，都會從新運行測試，就像npm start從新編譯代碼同樣。

觀察者包括交互式命令行界面，具備運行全部測試的能力，或專一於搜索模式。它是這樣設計的，以便你能夠保持它開啓並享受快速從新運行。你能夠從「Watch Usage」筆記中瞭解每次運行後觀察者打印的命令：

Version Control Integration

默認狀況下，當您運行npm test時，Jest將僅運行與上次提交後更改的文件相關的測試。這是一個優化，旨在使你的測試運行快速，不管您有多少測試。可是，它假定你不常常提交不經過測試的代碼。

Jest將始終明確提到，它只運行與上次提交後更改的文件相關的測試。你也能夠在觀察者模式按a 強制Jest運行全部測試。

Jest將始終在持續集成服務器上運行全部測試，或者該項目不在Git或Mercurial資源庫中。

Writing Tests

要建立測試，請使用測試名稱及其代碼添加在it()（或test()）塊。你能夠選擇將它們包裝在describe()塊中進行邏輯分組，但這不是必需的，也不是推薦的。

Jest提供了一個內置的expec()全局函數來進行斷言。基本測試可能以下所示：

import sum from './sum';

it('sums numbers', () => {
  expect(sum(1, 2)).toEqual(3);
  expect(sum(2, 2)).toEqual(4);
});

Jest支持的全部expect() 匹配器都在這裏進行了普遍的記錄。
你也可使用[jest.fn()和expect(fn).toBeCalled()]建立「spies」或模擬函數。

Testing Components

有普遍的組件測試技術。它們的範圍從「冒煙測試（smoke test）」來驗證組件渲染器沒有錯誤拋出，到淺渲染來測試某些輸出，到徹底渲染來測試組件生命週期和狀態更改。

不一樣的項目根據組件變化的頻率及其包含的邏輯選擇不一樣的測試權衡。若是你還沒有決定測試策略，咱們建議你首先爲組件建立簡單的冒煙測試：

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';

it('renders without crashing', () => {
  const div = document.createElement('div');
  ReactDOM.render(<App />, div)
});

該測試加載一個組件，並確保它在渲染過程當中沒有拋出錯誤。這樣的測試用不多的影響提供了不少價值，因此他們是偉大的起點，這個測試你能夠在src/App.test.js中找到。

當你遇到由更改組件致使的錯誤時，你將深刻了解其中哪些部分在你的應用程序中值得測試。這多是引入更具體的測試來判斷具體的預期輸出或行爲的好時機。

若是你想要脫離他們渲染的子組件來測試組件，咱們建議使用Enzyme中的shallow() rendering API。你也能夠寫冒煙測試：

npm install --save-dev enzyme react-addons-test-utils

import React from 'react';
import { shallow } from 'enzyme';
import App from './App';

it('renders without crashing', () => {
  shallow(<App />);
});

與之前使用ReactDOM.render() 的冒煙測試不一樣，此測試僅渲染<App>，而不會更深刻。例如，即便<App>自己渲染的<Button> 拋出了錯誤，此測試也將經過。淺渲染很是適合獨立的單元測試，但你仍然可能須要建立一些完整的渲染測試，以確保組件正確集成。 Enzyme支持使用mount() 全渲染，還可使用它來測試狀態更改和組件生命週期。

你能夠閱讀Enzyme文檔瞭解更多測試技術。 Enzyme文檔使用Chai和Sinon做爲斷言，但你沒必要使用它們，由於Jest爲spies提供了內置的expect() 和jest.fn()。

如下是Enzyme文檔中的一個例子，該文檔聲明瞭特定輸出，使用Jest匹配器重寫：

import React from 'react';
import { shallow } from 'enzyme';
import App from './App';

it('renders welcome message', () => {
  const wrapper = shallow(<App />);
  const welcome = <h2>Welcome to React</h2>
  // expect(wrapper.contains(welcome)).to.equal(true)
  expect(wrapper.contains(welcome)).toEqual(true)
});

全部Jest匹配器在這裏被普遍記錄。
不過，以下所述，你可使用像Chai這樣的第三方斷言庫。

此外，你可能會發現jest-enzyme有助於使用可讀的匹配器簡化你的測試。以上contains代碼用jest-enzyme更簡單。

expect(wrapper).toContainReact(welcome)

要使用Create React App設置jest-enzyme，請按照初始化測試環境的說明導入jest-enzyme。

npm install --save-dev jest-enzyme

// src/setupTests.js
import 'jest-enzyme';

Using Third Party Assertino Libraries

咱們建議你用expect() 的斷言和jest.fn()做爲spies。若是你遇到問題，請提交給Jest，咱們會解決這些問題。咱們打算繼續使他們更好的React，例如，美麗打印React元素做爲JSX。

可是，若是你習慣於其餘庫，例如Chai和Sinon，或者若是你現有的代碼使用了你想要移植的代碼，那麼你能夠正常導入它們：

import sinon from 'sinon';
import { expect } from 'chat';

而後在你的測試中像你一般那樣使用它們。

Initializing Test Environment

注意：這個特性須要react-scripts@0.4.0 版本以上。

在測試中，若是你的應用程序須要模擬瀏覽器API，或者在運行測試以前須要全局設置，請將src/setupTests.js添加到你的項目中。它將在運行測試以前自動執行。

例如：

src/setupTests.js

const localStorageMoke = {
  getItem: jest.fn(),
  setItem: jest.fn(),
  clear: jest.fn()
};
global.localStorage = localStorageMoke

Focusing and Excluding Tests

你能夠用xit() 替換it() 以臨時排除將要執行的測試。
一樣，fit() 可讓你專一於特定的測試，而無需運行任何其餘測試。

Coverage Reporting

Jest有一個集成的覆蓋報告，與ES6工做良好，不須要配置。
運行npm test -- --coverage（注意在中間的額外的-- ）包括覆蓋報告以下所示：

請注意，測試的運行速度要慢得多，所以建議你從正常的工做流程中分離運行它。

Continuous Integration

默認狀況下，npm test使用交互式CLI運行觀察器。可是，您能夠強制運行測試一次，並經過設置一個名爲CI的環境變量來完成該過程。

當使用npm run build 建立應用程序的構建時，默認狀況下不會檢查linter警告。像npm test 同樣，你能夠經過設置環境變量CI來強制構建執行linter警告檢查。若是遇到任何警告，則構建失敗。

流行的CI服務器默認已經設置了環境變量CI，但你也能夠本身作這個：

On CI servers

Travis CI

按照Travis Getting started指南，將你的GitHub 倉庫與Travis 同步。你能夠須要在我的資料頁面手動初始化某些設置。
在你的git 倉庫中添加.travis.yml 文件。

language: node_js
node_js:
  - 4
  - 6
cache:
  directories:
    - node_modules
scripts:
  - npm test
  - npm run build

經過git push 觸發第一次構建。
配置你的Travis CI 構建，若是須要。

On your own environment

Windows(cmd.exe)

set CI=true&&npm test

set CI=true&&npm run build

（注意：空格的缺失是有意的）

Linux, macOS(Bash)

CI=true npm test

CI=true npm run build

測試命令將強制Jest運行測試一次，而不啓動觀察器。

若是你發現本身在開發中常常遇到這種狀況，請提出一個問題來告訴咱們你的用例，由於咱們但願讓觀察者有最佳體驗，而且能夠隨時更改工做流程以適應更多的工做流程。

構建命令將檢查linter警告，若是找到任何警告，則會失敗。

Disabling jsdom

默認的，生成項目的package.json 像這樣：

// ...
  "scripts": {
    // ...
    "test": "react-scripts test --env=jsdom"
  }

若是你知道沒有一個測試依賴於jsdom，你能夠安全地刪除--env=jsdom，你的測試運行得更快。

爲了幫助您解決問題，如下是須要jsdom的API列表：

任何像window 和document 的瀏覽器全局變量
ReactDOM.render()
TestUtils.renderIntoDocument()（上述的一個簡寫）
Enzyme 中的mount()

相反，下面APIjsdom 不是必須的

'TestUitls.createRenderer()'（淺渲染）
Enzyme 中的shallow()

最後，對於snapshot testing jsdom 也不是必須的。

Snapshot Testing

Snapshot testing是Jest的一個功能，可自動生成組件的文本快照並將其保存在磁盤上，以便在UI輸出更改時，你能夠在不在組件輸出上手動寫入任何斷言的狀況下得到通知。詳細瞭解snapshot testing。

Editor Integration

若是你使用Visual Studio Code，則有一個Jest擴展能夠與Create React App開箱即用。這在使用文本編輯器時提供了不少相似IDE的功能：使用潛在的故障消息內聯顯示測試運行的狀態，自動啓動和中止觀察器，並提供一鍵式快照更新。

Developing Components in Isolation

一般，在應用程序中，你有不少UI組件，而且它們每一個都有許多不一樣的狀態。例如，一個簡單的按鈕組件能夠具備如下狀態：

帶有文本標籤。
用表情符號。
禁用模式。

一般，若是不運行示例應用程序或一些示例，很難看到這些狀態，。

默認狀況下，Create React App不包含這些工具，但你能夠輕鬆地將React Storybook添加到你的項目中。 它是一個第三方工具，可以讓你開發組件，並與你的應用程序隔離，查看全部狀態。

你也能夠將Storybook部署爲靜態應用。這樣，你的團隊中的每一個人均可以查看和查看UI組件的不一樣狀態，而無需啓動後端服務器或在應用程序中建立一個賬戶。

如何在你的應用中設置Storybook

首先，全局安裝下面npm 包

npm install -g getstorybook

而後，在你的應用目錄中運行下面命令：

getstorybook

以後，按照屏幕上的說明。

瞭解更多React Storybook：

屏幕錄像：Getting Started with React Storybook
GitHub Repo
文檔
React Storybook 的Snapshot Testing

Making a Progressive Web App

你能夠按照此倉庫中的步驟將你的React應用程序轉換爲Progressive Web App。

Deployment

npm run build 爲你應用程序的生產構建建立一個build目錄。設置你最喜歡的HTTP服務器，以便爲你的站點的訪問者提供index.html，而且請求靜態路徑像/static/js/main.<hash>.js獲取/static/js/main.<hash>.js 文件的內容。

Static Server

對於使用Node的環境，處理這種狀況的最簡單的方法是安裝serve並讓其處理rest：

npm install -g serve
serve -s build

上面顯示的最後一個命令將在端口5000上爲你的靜態站點提供服務。像許多serve的內部設置同樣，端口可使用-p或--port標誌進行調整。

運行此命令以獲取可用選項的完整列表：

serve -h

Serving Apps with Client-Side Routing

若是在底層，你使用了HTML5 pushState history API的路由器（例如，使用browserHistory的React Router），則許多靜態文件服務器將失敗。例如，若是你的React Router 中的route 使用/todos/42，則開發服務器將正確響應localhost：3000/todos/42，可是Express 服務器的生產版本將失敗。

這是由於當/todos/42 做爲新的頁面加載時，服務器會查找build/todos/42文件，可是找不到。服務器須要配置爲經過index.html來響應/todos/42的請求。例如，咱們能夠修改咱們上面的Express示例，爲任何未知路徑提供index.html：

app.use(express.static('./build'));

 -app.get('/', function(req, res))
 +app.get('/*', function(req, res)){
   res.sendFile(path.join(__dirname, './build', 'index.html'));
 }

若是你使用Apache，則須要在public文件夾中建立一個.htaccess文件，以下所示：

Options -MultiViews
  RewriteEngine On
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^ index.html [QSA,L]

運行npm run build時，它將被複制到build文件夾。

如今，對/todos/42 的請求將在開發和生產中都被正確處理。

Building for Relative Paths

默認狀況下，Create React App會生成一個構建，假設你的應用程序是託管在服務器根目錄。
要覆蓋它，請指定package.json中的homepage，例如：

"homepage": "http://mywebsite.com/relativepath"

這將使Create React App正確地推斷在生成的HTML文件中使用的根路徑。

Serving the Same Build from Different Paths

注意：這個特性須要react-scripts@0.9.0 版本以上。

若是你沒有使用HTML5 pushState history API，或者根本不使用客戶端路由，則無需指定服務應用程序的URL。相反，你能夠把它放在你的package.json中：

"homepage": ".",

這將確保全部資源路徑都相對於index.html。而後，你能夠將你的應用程序從http://mywebsite.com 移動到http://mywebsite.com/relativepath 甚至是http://mywebsite.com/relative/path，而無需從新構建它。

Azure

請參閱此博文，瞭解如何將React應用程序部署到Microsoft Azure。

Firebase

若是你還沒有運行npm install -g firebase-tools，請安裝Firebase CLI。註冊一個Firebase賬戶並建立一個新項目。運行firebase login並使用之前建立的Firebase賬戶登陸。

而後從項目的根目錄運行firebase init命令。你須要選擇Hosting：Configure and deploy Firebase Hosting sites，並選擇你在上一步驟中建立的Firebase項目。你將須要贊成正在建立的database.rules.json，選擇build做爲公共目錄，並經過回覆y來贊成Configuire as a single-page app。

=== Project Setup

   First, let's associate this project directory with a Firebase project.
   You can create multiple project aliases by running firebase use --add,
   but for now we'll just set up a default project.

   ? What Firebase project do you want to associate as default? Example app (example-app-fd690)

   === Database Setup

   Firebase Realtime Database Rules allow you to define how your data should be
   structured and when your data can be read from and written to.

   ? What file should be used for Database Rules? database.rules.json
   ✔  Database Rules for example-app-fd690 have been downloaded to database.rules.json.
   Future modifications to database.rules.json will update Database Rules when you run
   firebase deploy.

   === Hosting Setup

   Your public directory is the folder (relative to your project directory) that
   will contain Hosting assets to uploaded with firebase deploy. If you
   have a build process for your assets, use your build's output directory.

   ? What do you want to use as your public directory? build
   ? Configure as a single-page app (rewrite all urls to /index.html)? Yes
   ✔  Wrote build/index.html

   i  Writing configuration info to firebase.json...
   i  Writing project information to .firebaserc...

   ✔  Firebase initialization complete!

如今，在使用npm run build 建立生產構建以後，能夠經過運行firebase deploy進行部署。

=== Deploying to 'example-app-fd690'...

i  deploying database, hosting
✔  database: rules ready to deploy.
i  hosting: preparing build directory for upload...
Uploading: [==============================          ] 75%✔  hosting: build folder uploaded successfully
✔  hosting: 8 files uploaded successfully
i  starting release process (may take several minutes)...

✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/example-app-fd690/overview

更多信息請看添加Firebase 到你的JavaScript 項目。

Github Pages

注意：這個特性須要react-scripts@0.2.0 版本以上。

Step 1：Add homepage to package.json

下面的步驟很重要！
若是你跳過它，你的應用程序將沒法正確部署。

打開你的package.json，添加homepage 域：

"homepage": "https://myusername.github.io/my-app",

Create React App 使用homepage 來肯定構建的HTML文件中的根URL。

Step 2:
Install gh-pages and add 'deploy' to 'scripts' in package.json

如今，每當運行npm run build時，你將看到一個備忘單，其中包含如何部署到GitHub Pages的說明。

要發佈在 https://myusername.github.io/my-app，請運行：

npm install --save-dev gh-pages

在package.json 中添加下面腳本：

// ...
  "scripts": {
    // ...
    "predeploy": "npm run build",
    "deploy": "gh-pages -d build"
  }

predeploy 會在運行deploy 以前自動運行。

Step 3：Deploy the site by running npm rung deploy

而後運行：

npm run deploy

Step 4: Ensure your project's settings use gh-pages

最後，確保GitHub項目設置中的GitHub Pages選項設置爲使用gh-pages分支：

Step 5: Optionally, configure the domain

你能夠經過將CNAME文件添加到public/文件夾來配置具備GitHub Pages的自定義域。

Notes on client-side routing

GitHub Pages 在底層不支持使用HTML5 pushState history API的路由器（例如，使用browserHistory的React Router）。這是由於當一個網址載入新的頁面時，如http://user.github.io/todomvc/todos/42，其中/todos/42是前端路由，GitHub Pages服務器返回404，由於它不知道/todos/42 任何事。若是要將路由器添加到GitHub Pages上託管的項目，如下是一些解決方案：

你能夠從使用HTML5 history API切換到使用哈希的路由。若是你使用React Router，你能夠切換到hashHistory 實現此效果，可是該URL會更長更詳細（例如，http://user.github.io/todomvc/#/todos/42?_k=yknaj）。閱讀有關React Router中不一樣歷史記錄實現的更多信息。
或者，你可使用一個技巧來教導GitHub Pages經過使用特殊的重定向參數重定向到你的index.html頁面來處理404.html。在部署項目以前，你須要將一個包含重定向代碼的404.html文件添加到build文件夾中，而且你須要添加將redirect參數處理的代碼到index.html。你能夠在本指南中找到此技術的詳細說明。

Heroku

使用Heroku Buildpack for Create React App。
你能夠在Deploying React with Zero Configuration 找到介紹。

Resolving Heroku Deployment Errors

有時npm run build 在本地工做，但在部署期間經過Heroku失敗。如下是最多見的狀況。

"Module not found:Error:Cannot resolve 'file' or 'directory'"

若是你獲得這樣的東西：

remote: Failed to create a production build. Reason:
remote: Module not found: Error: Cannot resolve 'file' or 'directory'
MyDirectory in /tmp/build_1234/src

這意味着你須要確保import的文件或目錄的文字大小符合你在文件系統或GitHub上看到的文件或目錄。

這很重要，由於Linux（Heroku使用的操做系統）區分大小寫。因此MyDirectory和mydirectory是兩個不一樣的目錄，所以，儘管項目在本地構建成，可是區別在於破壞Heroku 遠程上的import語句。

"Could not find a required file."

若是從包中排除或忽略必需的文件，你將看到相似於如下錯誤：

remote: Could not find a required file.
remote:   Name: `index.html`
remote:   Searched in: /tmp/build_a2875fc163b209225122d68916f1d4df/public
remote:
remote: npm ERR! Linux 3.13.0-105-generic
remote: npm ERR! argv "/tmp/build_a2875fc163b209225122d68916f1d4df/.heroku/node/bin/node" "/tmp/build_a2875fc163b209225122d68916f1d4df/.heroku/node/bin/npm" "run" "build"

在這種狀況下，請確保該文件位於正確的大小寫，而且在本地.gitignore或~/.gitignore_global上不被忽略。

Modulus

請參閱Modulus博客文章，瞭解如何將你的react應用部署到Modulus。

Netlify

To do a manual deploy to Netlify's CDN

npm install netlify-cli
netlify deploy

選擇build 做爲部署路徑。

To setup continuous delivery:

使用此設置，當你push a git或open a pull request 時，Netlify將構建和部署：

啓動一個新的netlify項目
選擇你的Git託管服務並選擇你的倉庫
單擊Build your site

Support for client-side routing:

要支持pushState，請確保使用如下重寫規則建立一個public/_redirects文件：

/ * /index.html 200

構建項目時，Create React App會將public文件夾內容放入構建輸出。

Now

now提供零配置的單命令部署。

now能夠經過推薦的桌面工具或經過node 的npm install -g now。
經過運行npm install --save serve來安裝serve。
將此行添加到package.json中的scripts中：

"now-start": "serve build/",

在從你的項目目錄中運行now。你的輸出中將會顯示一個now.shURL，以下所示：

> Ready! https://your-project-dirname-tpspyhtdtk.now.sh (copied to clipbord)

構建完成後，將該URL粘貼到瀏覽器中，你將看到已部署的應用程序。

本文提供了詳細信息。

S3 and CloudFront

請參閱此博文，介紹如何將你的React應用程序部署到Amazon Web Services S3和CloudFront。

Surge

若是你還沒有運行npm install -g surge，請安裝Surge CLI。運行surge命令並登陸或建立一個新賬戶。

當詢問項目路徑時，請確保指定build文件夾，例如：

project path: /path/to/project/build

請注意，爲了支持使用HTML5 pushState API的路由器，你可能須要將構建文件夾中的index.html從新命名爲200.html，而後再部署到Surge。這樣能夠確保每一個URL都回退該文件。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。