如何開發由Create-React-App 引導的應用(三)


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

系列文章

  1. 如何開發由Create-React-App 引導的應用
  2. 如何開發由Create-React-App 引導的應用(一)
  3. 如何開發由Create-React-App 引導的應用(二)
  4. 如何開發由Create-React-App 引導的應用(四)

Integrating with an API Backend

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

Node

看看這個教程。 您可以在這里找到配套的GitHub存儲庫

Ruby on Rails

看看這個教程。 您可以在這里找到配套的GitHub存儲庫

Proxying API Requests in Development

注意:這個特性需要react-scripts@0.2.3 版本以上。

人們通過提供與前端React 應用相同的主機和端口作為后端實現。
例如,應用部署后,生產設置可能看上去像這樣:

/             - 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') 這樣的請求而不必擔心在開發過程中將它們重定向到另一個主機或端口。

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

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

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

方便的,這樣可以避免在開發過程中發生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 選項對你不夠靈活,或者你可以:

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.jsApp.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

但是,如果你習慣於其他庫,例如ChaiSinon,或者如果你現有的代碼使用了你想要移植的代碼,那么你可以正常導入它們:

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

  1. 按照Travis Getting started指南,將你的GitHub 倉庫與Travis 同步。你可以需要在個人資料頁面手動初始化某些設置。
  2. 在你的git 倉庫中添加.travis.yml 文件。
language: node_js
node_js:
  - 4
  - 6
cache:
  directories:
    - node_modules
scripts:
  - npm test
  - npm run build
  1. 通過git push 觸發第一次構建。
  2. 配置你的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列表:

相反,下面APIjsdom 不是必須的

最后,對於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:

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

Other Solutions

你不一定需要靜態服務器才能在生產中運行Create React App 項目。 它的工作也能很好集成到一個現有的動態項目中。

以下是使用Node和Express的編程示例:

const express = require('express');
const path = require('path');
const app = express();

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

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

app.listen(5000)

你的服務器軟件的選擇也不重要。 由於Create React App完全與平台無關,因此無需明確使用Node。

具有靜態資源的build文件夾是Create React App生成的唯一輸出。

但是,如果你使用客戶端路由,這還不夠。 如果你希望在單頁應用程序中支持像/todos/42 這樣的URL,請閱讀下一節。

Serving Apps with Client-Side Routing

如果在底層,你使用了HTML5 pushState history API的路由器(例如,使用browserHistoryReact 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使用的操作系統)區分大小寫。 所以MyDirectorymydirectory是兩個不同的目錄,因此,盡管項目在本地構建成,但是區別在於破壞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將構建和部署:

  1. 啟動一個新的netlify項目
  2. 選擇你的Git托管服務並選擇你的倉庫
  3. 單擊Build your site

Support for client-side routing:

要支持pushState,請確保使用以下重寫規則創建一個public/_redirects文件:

/ * /index.html 200

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

Now

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

  1. now可以通過推薦的桌面工具或通過node 的npm install -g now
  2. 通過運行npm install --save serve來安裝serve
  3. 將此行添加到package.json中的scripts中:
  "now-start": "serve build/",
  1. 在從你的項目目錄中運行now。 你的輸出中將會顯示一個now.shURL,如下所示:
> Ready! https://your-project-dirname-tpspyhtdtk.now.sh (copied to clipbord)

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

本文提供了詳細信息。

S3 and CloudFront

請參閱此博文,介紹如何將你的React應用程序部署到Amazon Web Services S3CloudFront

Surge

如果你尚未運行npm install -g surge,請安裝Surge CLI。 運行surge命令並登錄或創建一個新帳戶。

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

  project path: /path/to/project/build

請注意,為了支持使用HTML5 pushState API的路由器,你可能需要將構建文件夾中的index.html重新命名為200.html,然后再部署到Surge。 這樣可以確保每個URL都回退該文件


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM