摘要：在官方庫(kù)的多主題中進(jìn)行有效的使用。項(xiàng)目中默認(rèn)選擇使用可以假設(shè)是安全的。常規(guī)提交定義了強(qiáng)制類(lèi)型可選范圍其次是提交消息。標(biāo)準(zhǔn)版本將正確地撞擊項(xiàng)目的主要版本，因?yàn)樵谔峤恢黧w中存在著關(guān)鍵字。

使用Angular CLI開(kāi)發(fā)angular應(yīng)用程序是一種非常愉快的體驗(yàn)！Angular團(tuán)隊(duì)為我們提供了令人驚嘆的CLI，它支持了任何重要項(xiàng)目開(kāi)箱即用所需的大部分東西。

規(guī)范化的項(xiàng)目結(jié)構(gòu)與全面的測(cè)試能力（包括單元測(cè)試和端到端測(cè)試），腳手架，支持使用特定的環(huán)境配置去構(gòu)建產(chǎn)品。這在構(gòu)建每一個(gè)新項(xiàng)目時(shí)候節(jié)約了大量時(shí)間。感謝Angular團(tuán)隊(duì)！?

雖然Angular CLI的工作的很好，但我們可以利用一些潛在的配置和最佳實(shí)踐使我們的項(xiàng)目更好！

具有Core(核心)，Shared(共享)，lazy-loaded Feature modules(延遲加載功能模塊)體系結(jié)構(gòu)的最佳實(shí)踐

為app和environments文件夾使用別名來(lái)支持更干凈的導(dǎo)入

為什么和如何使用Sass ，Angular Material

如何組織好的產(chǎn)品構(gòu)建方式

如何向PhantomJS說(shuō)再見(jiàn)以及使用Headless Chrome來(lái)替代(測(cè)試)

如何發(fā)布我們的項(xiàng)目通過(guò)自動(dòng)生成更新日志和正確的版本號(hào)

好的, 我們使用Angular CLI生成了新的項(xiàng)目，但是現(xiàn)在呢？我們應(yīng)該繼續(xù)在一些隨機(jī)文件夾生成我們的服務(wù)和組件嗎？我們應(yīng)該如何組織我們的項(xiàng)目？

一個(gè)好的指導(dǎo)原則應(yīng)該是遵循將應(yīng)用程序分成至少三個(gè)不同的模塊：?Core(核心模塊), Shared(共享模塊) 和 Feature(功能模塊) (不過(guò)我們可能需要更多的功能模塊。?).

所有服務(wù)都應(yīng)該在核心模塊實(shí)現(xiàn)。典型的例子比如認(rèn)證服務(wù)或用戶(hù)服務(wù)。讓我們看個(gè)例子。

/* 3rd party libraries */
import { NgModule, Optional, SkipSelf } from "@angular/core";
import { CommonModule } from "@angular/common";
import { HttpClientModule } from "@angular/common/http";

/* our own custom services  */
import { SomeSingletonService } from "./some-singleton/some-singleton.service";

@NgModule({
  imports: [
    /* 3rd party libraries */
    CommonModule,
    HttpClientModule,
  ],
  declarations: [],
  providers: [
    /* our own custom services  */
    SomeSingletonService
  ]
})
export class CoreModule {
  /* make sure CoreModule is imported only by one NgModule the AppModule */
  constructor (
    @Optional() @SkipSelf() parentModule: CoreModule
  ) {
    if (parentModule) {
      throw new Error("CoreModule is already loaded. Import only in AppModule");
    }
  }
}

所有的“dumb(啞)”組件和管道都應(yīng)該在這里實(shí)現(xiàn)。這些組件不能從核心模塊或其他特性模塊的構(gòu)造函數(shù)中的導(dǎo)入和注入服務(wù)。它們應(yīng)該使用組件的模板中的屬性接收所有數(shù)據(jù)。這一切都?xì)w結(jié)到這一事實(shí)，SharedModule(共享模塊)沒(méi)有任何依賴(lài)于我們的應(yīng)用程序的其余部分。

這也是導(dǎo)入和重新導(dǎo)入Angular Material 組件庫(kù)的完美場(chǎng)所。

/* 3rd party libraries */
import { NgModule } from "@angular/core";
import { CommonModule } from "@angular/common";
import { FormsModule  } from "@angular/forms";
import { MdButtonModule } from "@angular/material";

/* our own custom components */
import { SomeCustomComponent } from "./some-custom/some-custom.component";

@NgModule({
  imports: [
    /* angular stuff */
    CommonModule,
    FormsModule,

    /* 3rd party components */
    MdButtonModule,
  ],
  declarations: [
    SomeCustomComponent
  ],
  exports: [
    /* angular stuff */
    CommonModule,
    FormsModule,

    /* 3rd party components */
    MdButtonModule,

    /* our own custom components */
    SomeCustomComponent
  ]
})
export class SharedModule { }

我們可以在創(chuàng)建新項(xiàng)目后立即生成核心和共享模塊。這樣，我們就可以從一開(kāi)始就準(zhǔn)備生成額外的組件和服務(wù)。

運(yùn)行命令ng generate module core生成核心模塊。然后在core文件夾創(chuàng)建index.ts文件，再重新導(dǎo)出CoreModule。我們將重新導(dǎo)出額外的公共服務(wù)，這些服務(wù)在整個(gè)開(kāi)發(fā)過(guò)程中都可以使用。

完成后，我們可以對(duì)shared module(共享模塊)執(zhí)行同樣的操作。

我們將為應(yīng)用程序的每一個(gè)獨(dú)立特性創(chuàng)建多個(gè)功能模塊。Feature modules(功能模塊)應(yīng)該只能從CoreModule導(dǎo)入服務(wù)。如果功能模塊A需要從功能模塊B導(dǎo)入服務(wù)，可以考慮將該服務(wù)遷移到CoreModule。

在某些情況下，需要只是某些功能模塊共享的服務(wù)，將它們移動(dòng)到核心是沒(méi)有意義的。在這種情況下，我們可以創(chuàng)建特殊的共享功能模塊，如本文后面所述。

經(jīng)驗(yàn)法則是： 我們創(chuàng)建的功能模塊盡量不依賴(lài)其他功能模塊，僅僅服務(wù)由CoreModule提供，組件由SharedModule提供

這將保持我們的代碼干凈，易于維護(hù)和擴(kuò)展的新功能。它還減少了重構(gòu)所需的工作量。如果遵循得當(dāng)，我們將確信對(duì)一個(gè)功能的更改不會(huì)影響或破壞我們的應(yīng)用程序的其余部分。

我們應(yīng)該盡可能延遲加載我們的功能模塊。理論上，只有一個(gè)功能模塊應(yīng)該在應(yīng)用程序啟動(dòng)時(shí)同步加載以顯示初始內(nèi)容。每個(gè)其他功能模塊應(yīng)該在用戶(hù)觸發(fā)導(dǎo)航后緩慢加載。

我們的app 和 environments文件夾使用別名將使我們能夠?qū)崿F(xiàn)干凈的導(dǎo)入，在我們的應(yīng)用程序這將是一致的。

假設(shè)，但通常情況。我們正在研究一個(gè)組件，它位于功能模塊A中的三個(gè)文件夾深處，我們希望從核心模塊中導(dǎo)入位于兩個(gè)文件夾深處的服務(wù)。這將導(dǎo)致導(dǎo)入聲明看起來(lái)有點(diǎn)像import { SomeService } from "../../../core/subpackage1/subpackage2/some.service"。

絕對(duì)不是最干凈的導(dǎo)入申明…

更糟糕的是，每當(dāng)我們想改變這兩個(gè)文件中任何一個(gè)的位置時(shí)，我們的導(dǎo)入語(yǔ)句都會(huì)中斷。相比之下，更短的導(dǎo)入申明import { SomeService } from "@app/core"?？雌饋?lái)更好，不是嗎？

能夠使用別名必須添加URL地址和路徑屬性，我們tsconfig.json文件像這樣…

{
  "compilerOptions": {
    "...": "reduced for brevity",
    
    "baseUrl": "src",
    "paths": {
      "@app/*": ["app/*"],
      "@env/*": ["environments/*"]
    }
  }
}

我們還添加了@env別名，以便能夠從import { environment } from "@env/environment"中使用同一個(gè)導(dǎo)入申明輕松地從應(yīng)用程序的任何地方訪問(wèn)環(huán)境變量。它將為所有指定的environments工作，因?yàn)樗鼘⒏鶕?jù)傳遞給ng build命令的--env標(biāo)志自動(dòng)解析正確的環(huán)境配置文件。

通過(guò)我們的路徑，我們現(xiàn)在可以像這樣導(dǎo)入environment 和 services …

/* 3rd party libraries */
import { Component, OnInit } from "@angular/core";
import { Observable } from "rxjs/Observable";

/* globally accessible app code (in every feature module) */
import { SomeSingletonService } from "@app/core";
import { environment } from "@env/environment";

/* localy accessible feature module code, always use relative path */
import { ExampleService } from "./example.service";

@Component({
  /* ... */
})
export class ExampleComponent implements OnInit {
  constructor(
    private someSingletonService: SomeSingletonService,
    private exampleService: ExampleService
  ) {}
}

在上面的例子中，你也許注意到我們直接導(dǎo)入服務(wù)SomeSingletonService是通過(guò)@app/core，代替了@app/core/some-package/some-singleton.service。這得感謝核心模塊的入口文件index.ts重新導(dǎo)出了每一個(gè)公共實(shí)體。我們?cè)诿恳粋€(gè)包(文件夾)都創(chuàng)建了一個(gè)文件index.ts，它看起來(lái)像這樣...

export * from "./core.module";
export * from "./auth/auth.service";
export * from "./user/user.service";
export * from "./some-singleton-service/some-singleton.service";

在大多數(shù)的應(yīng)用程序中，特殊功能模塊的組件和服務(wù)的通常只需要訪問(wèn)服務(wù)的 CoreModule 和組件的SharedModule。有時(shí)這可能不足以解決特定的業(yè)務(wù)情況，我們還需要某種“shared feature module(共享功能模塊)”，它為其他功能模塊的有限子集提供功能。

在這種情況下，我們將得到類(lèi)似的東西import { SomeService } from "@app/shared-feature";。和核心模塊一樣，共享功能模塊使用別名@app進(jìn)行訪問(wèn)。

SASS是一個(gè)CSS的預(yù)處理器，支持有趣的東西，像variables(盡管CSS將要實(shí)現(xiàn)變量），functions，mixin等等。

SASS在Angular Material Components官方庫(kù)的多主題中進(jìn)行有效的使用。項(xiàng)目中默認(rèn)選擇使用SASS可以假設(shè)是安全的。

為了使用SASS我們?cè)谑褂肁ngular CLI生成我們的項(xiàng)目時(shí)候必須用命令ng new command --style scss 。這就設(shè)置了大部分必須的配置。默認(rèn)情況下不添加stylePreprocessorOptions includePaths，我們可以自己設(shè)置成根目錄 "./" 和 可選的 "./themes"。

{
  "apps": [
    {
      "...": "reduced for brevity",
      
      "stylePreprocessorOptions": {
        "includePaths": ["./", "./themes"]
      }
    }
  ]
}

這有助于我們的編輯器找到導(dǎo)入標(biāo)志，并且通過(guò)Angular Material的變量和工具函數(shù)的代碼完成來(lái)增強(qiáng)開(kāi)發(fā)人員的體驗(yàn)。

When theming Angular Material apps it’s a good practice to extract theme definitions into separate themes folder, one theme per file.

Angular CLI聲稱(chēng)的項(xiàng)目只提供了一個(gè)非常簡(jiǎn)單開(kāi)箱即用的構(gòu)建腳本ng build。為了生成產(chǎn)品級(jí)的工件，我們必須自己做一些定制。

我們?cè)趐ackage.json中添加腳本"build:prod": "ng build --target production --build-optimizer --vendor-chunk" 。

這是一個(gè)標(biāo)志能使代碼壓縮，以及還有很多默認(rèn)的有用的構(gòu)建標(biāo)志。使用如下：

--environment prod —使用 environment.prod.ts 文件設(shè)置環(huán)境變量

--aot?—預(yù)編譯，提前編譯. 這將在未來(lái)的Angular CLI是默認(rèn)設(shè)置，但是現(xiàn)在我們必須手動(dòng)啟動(dòng)。

--output-hashing all?—?將生成的文件的散列內(nèi)容添加到文件名中，以方便瀏覽器緩存破壞（文件內(nèi)容的任何更改都會(huì)導(dǎo)致不同的哈希值，因此瀏覽器被迫加載新版本的文件）

--extract-css true?—?將所有的css提取到到多帶帶的樣式表文件

--sourcemaps false?—?禁用source maps的生成

--named-chunks false?—?禁用使用可讀的名字，用數(shù)字替代

--build-optimizer?—?新的功能，導(dǎo)致更小的捆綁，但更長(zhǎng)的構(gòu)建時(shí)間，所以慎用?。▽?lái)也應(yīng)該默認(rèn)啟用）

--vendor-chunk?—?將所有第三方（庫(kù)）代碼提取到多帶帶的塊中

去官方文檔檢查其他有用的配置項(xiàng)，也許在個(gè)人項(xiàng)目中用得上。

PhantomJS是一個(gè)非常著名的無(wú)頭的瀏覽器。這是事實(shí)上的解決方案，在CI服務(wù)器和許多開(kāi)發(fā)機(jī)器上運(yùn)行前端測(cè)試。

雖然有好的，這是現(xiàn)代ECMAScript支持滯后。更重要的是，它是不規(guī)范的行為，在許多情況下導(dǎo)致頭痛，當(dāng)測(cè)試通過(guò)本地沒(méi)有問(wèn)題，但他們?nèi)匀辉贑I環(huán)境出現(xiàn)問(wèn)題。

幸運(yùn)的是，我們不再需要處理它了！

就像官方文檔說(shuō)的一樣…

Headless Chrome 是在Chrome 59上運(yùn)行。這是在Headless環(huán)境下運(yùn)行Chrome瀏覽器的一種方式。本質(zhì)上，運(yùn)行沒(méi)有Chrome的Chrome！它將Chrome和閃爍渲染引擎提供的所有現(xiàn)代Web平臺(tái)特性帶到命令行。

很棒，那我們?cè)贏ngular CLI上使用它呢？

我們?cè)趐ackage.json上添加腳本"test": "ng test --browser ChromeHeadless --single-run" 和 "watch": "ng test --browser ChromeHeadless"

很簡(jiǎn)單，對(duì)吧！

對(duì)我們感興趣的項(xiàng)目的新特性和bug修復(fù)有一個(gè)快速概述總是很棒的。

讓我們?yōu)橛脩?hù)提供同樣的便利！

手動(dòng)寫(xiě)更改日志將是極其繁瑣，而且容易出錯(cuò)的任務(wù)，所以它最好是自動(dòng)化的過(guò)程。有很多可用的工具可以做這項(xiàng)工作，但是讓我們看下standard-version。

這個(gè)工具根據(jù)Conventional Commits specification把所有提交自動(dòng)生成和更新changelog.md文件，并且正確地確定我們項(xiàng)目的新版本。

常規(guī)提交定義了強(qiáng)制類(lèi)型、可選（范圍）：其次是提交消息。還可以添加可選的正文和頁(yè)腳，它們都由空行分隔。讓我們來(lái)看看ngx-model庫(kù)所有提交信息的一個(gè)實(shí)踐例子。

fix(dependency): multiple versions of rxjs in single project (TS90010)

BREAKING CHANGE: rxjs is now peerDependency instead of dependency

closes #1

標(biāo)準(zhǔn)版本將正確地撞擊(bump)項(xiàng)目的主要版本，因?yàn)樵谔峤恢黧w中存在著B(niǎo)REAKING CHANGE關(guān)鍵字。

生成的 CHANGELOG.md 文件將像這個(gè)樣子….

看起來(lái)很好！那么我們?nèi)绾卧谖覀兊捻?xiàng)目中使用它呢？

首先我們需要通過(guò)命令npm install -D standard-version安裝到devDependencies ，然后添加腳本"release": "standard-version"到package.json文件中。

我們也可以通過(guò)git push和npm publish使整個(gè)過(guò)程自動(dòng)化。本例子中使用腳本"release": "standard-version && git push?—?follow-tags origin master && npm publish"。

注意我們使用&&鏈接命令是平臺(tái)相關(guān)的，只能在基于Unix的系統(tǒng)上（因此也對(duì)Windows Cygwin，gitbash，或新的win10）。

IntelliJ IDEA永遠(yuǎn)不會(huì)找到所有默認(rèn)情況下(帶有錯(cuò)誤的標(biāo)記和殘廢的紅色代碼)的路徑。幸運(yùn)的是，解決方案非常簡(jiǎn)單。只需選擇SRC文件夾并將其標(biāo)記為Sources Root。

我希望你能找到一些有用的技巧和最佳實(shí)踐！請(qǐng)支持這篇文章，以便向更多的受眾傳播這些建議！

6 Best Practices & Pro Tips when using Angular CLI