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

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

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

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

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

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

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

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

如何向PhantomJS說再見以及使用Headless Chrome來替代(測試)

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

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

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

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

/* 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(共享模塊)沒有任何依賴于我們的應(yīng)用程序的其余部分。

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

/* 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)目后立即生成核心和共享模塊。這樣，我們就可以從一開始就準(zhǔn)備生成額外的組件和服務(wù)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通過我們的路徑，我們現(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是通過@app/core，代替了@app/core/some-package/some-singleton.service。這得感謝核心模塊的入口文件index.ts重新導(dǎo)出了每一個公共實(shí)體。我們在每一個包(文件夾)都創(chuàng)建了一個文件index.ts，它看起來像這樣...

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ù)的 CoreModule 和組件的SharedModule。有時這可能不足以解決特定的業(yè)務(wù)情況，我們還需要某種“shared feature module(共享功能模塊)”，它為其他功能模塊的有限子集提供功能。

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

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

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

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

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

這有助于我們的編輯器找到導(dǎo)入標(biāo)志，并且通過Angular Material的變量和工具函數(shù)的代碼完成來增強(qiáng)開發(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聲稱的項(xiàng)目只提供了一個非常簡單開箱即用的構(gòu)建腳本ng build。為了生成產(chǎn)品級的工件，我們必須自己做一些定制。

我們在package.json中添加腳本"build:prod": "ng build --target production --build-optimizer --vendor-chunk" 。

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

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

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

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

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

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

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

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

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

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

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

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

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

就像官方文檔說的一樣…

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

很棒，那我們在Angular CLI上使用它呢？

我們在package.json上添加腳本"test": "ng test --browser ChromeHeadless --single-run" 和 "watch": "ng test --browser ChromeHeadless"

很簡單，對吧！

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

讓我們?yōu)橛脩籼峁┩瑯拥谋憷?/em>

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

BREAKING CHANGE: rxjs is now peerDependency instead of dependency

closes #1

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