在業務系統需求規劃過程中，通常對於諸如組織機構、用戶和角色等這種基礎功能，通常是將這部分功能規劃到通用子域中，這也說明了，對於這部分功能來講，是系統的基石，整個業務體系是建立於這部分基石之上的，當然，還有諸如多語言、設置管理、認證和授權等。對於這部分功能，ABP中存在這些概念，並且通過Module Zero模塊完成了這些概念。

 

一、角色訪問控制之RBAC

　　RBAC：Role Based Access Control，基於角色的訪問控制，這在目前大多數軟件中來講已經算得上是普遍應用了，最常見的結構如下，結構簡單，設計思路清晰。

　　

　　但是也存在其它升級版的設計，諸如用戶權限表、角色組、用戶組的概念等，具體分類有RBAC0、RBAC1、RBAC2等，後者功能越來越強大，也越來越複雜。

• RBAC0：是RBAC的核心思想。
• RBAC1：是把RBAC的角色分層模型。
• RBAC2：增加了RBAC的約束模型。
• RBAC3：整合RBAC2 + RBAC1。

 

二、ABP中的RBAC

　　在Abp中，已經集成了這些概念，並在ModuleZero模塊中實現了這些概念，基於IdentityServer4的ModuleZero模塊完成了封裝。對於我們大多數以業務為中心的開發人員來講，不應該又去造一個輪子，而是應該開好這輛車。首先看下Abp中的RBAC模型

　　

　　在這其中權限表中記錄了用戶與權限，角色與權限兩部分。對於權限通常指的是功能權限和數據權限兩部分，一般來講，大多指的是功能權限，這種通過角色與權限進行管理即可，如還有用戶部分的功能區分，則可以再使用上用戶與權限，而對於數據權限，可以利用用戶與權限部分，個人用的比較少，但是，可以想象到這麼一個場景，針對於一家門店內的多個店長，角色相同即相應的權限相同，但各自關心的數據來源不同，關心東部、南部等數據，而不關心西部、北部數據，因此可以在數據層面進行劃分，比如設置數據來源，東南西北，對於數據來源進行權限關聯，這樣一來用戶本身如果擁有東部數據權限，則只能看到東部數據。

 

1、權限聲明及應用

　　在Abp中，需要首先在Core層/Authorization/PermissionNames.cs中聲明權限，Abp權限部分設計原則是：先聲明再使用。

/// <summary>
/// 權限命名
/// </summary>
public static class PermissionNames
{
    #region 頂級權限
    public const string Pages = "Pages";
    #endregion

    #region 基礎支撐平台
    public const string Pages_Frame = "Pages.Frame";

    #region 租戶管理
    public const string Pages_Frame_Tenants = "Pages.Frame.Tenants";
    #endregion

    #region 組織機構
    public const string Pages_Frame_OrganizationUnits = "Pages.Frame.OrganizationUnits";
    public const string Pages_Frame_OrganizationUnits_Create = "Pages.Frame.OrganizationUnits.Create";
    public const string Pages_Frame_OrganizationUnits_Update = "Pages.Frame.OrganizationUnits.Update";
    public const string Pages_Frame_OrganizationUnits_Delete = "Pages.Frame.OrganizationUnits.Delete";
    #endregion

    #region 用戶管理
    public const string Pages_Frame_Users = "Pages.Frame.Users";
    public const string Pages_Frame_Users_Create = "Pages.Frame.Users.Create";
    public const string Pages_Frame_Users_Update = "Pages.Frame.Users.Update";
    public const string Pages_Frame_Users_Delete = "Pages.Frame.Users.Delete";
    public const string Pages_Frame_Users_ResetPassword = "Pages.Frame.Users.ResetPassword";
    #endregion

    #region 角色管理
    public const string Pages_Frame_Roles = "Pages.Roles";
    public const string Pages_Frame_Roles_Create = "Pages.Frame.Roles.Create";
    public const string Pages_Frame_Roles_Update = "Pages.Frame.Roles.Update";
    public const string Pages_Frame_Roles_Delete = "Pages.Frame.Roles.Delete";
    #endregion

}

　　然後在Core層/Authorization/XXXAuthorizationProvider.cs中設置具體權限，在此處設置權限時，可以根據權限設計時候的職責劃分，比如如果僅僅是多租戶需要這部分，那便設置權限範圍為多租戶即可。

public class SurroundAuthorizationProvider : AuthorizationProvider
{
    public override void SetPermissions(IPermissionDefinitionContext context)
    {
        #region 頂級權限
        var pages = context.CreatePermission(PermissionNames.Pages, L("Pages"));
        #endregion

        #region 基礎支撐平台
        var frame = pages.CreateChildPermission(PermissionNames.Pages_Frame, L("Frame"));

        #region 租戶管理
        frame.CreateChildPermission(PermissionNames.Pages_Frame_Tenants, L("Tenants"), multiTenancySides: MultiTenancySides.Host);
        #endregion

        #region 組織機構
        var organizationUnits = frame.CreateChildPermission(PermissionNames.Pages_Frame_OrganizationUnits, L("OrganizationUnits"));
        organizationUnits.CreateChildPermission(PermissionNames.Pages_Frame_OrganizationUnits_Create, L("CreateOrganizationUnit"));
        organizationUnits.CreateChildPermission(PermissionNames.Pages_Frame_OrganizationUnits_Update, L("EditOrganizationUnit"));
        organizationUnits.CreateChildPermission(PermissionNames.Pages_Frame_OrganizationUnits_Delete, L("DeleteOrganizationUnit"));
        #endregion

        #region 用戶管理
        var users = frame.CreateChildPermission(PermissionNames.Pages_Frame_Users, L("Users"));
        users.CreateChildPermission(PermissionNames.Pages_Frame_Users_Create, L("CreateUser"));
        users.CreateChildPermission(PermissionNames.Pages_Frame_Users_Update, L("UpdateUser"));
        users.CreateChildPermission(PermissionNames.Pages_Frame_Users_Delete, L("DeleteUser"));
        users.CreateChildPermission(PermissionNames.Pages_Frame_Users_ResetPassword, L("ResetPassword"));
        #endregion

        #region 角色管理
        var roles = frame.CreateChildPermission(PermissionNames.Pages_Frame_Roles, L("Roles"));
        roles.CreateChildPermission(PermissionNames.Pages_Frame_Roles_Create, L("CreateRole"));
        roles.CreateChildPermission(PermissionNames.Pages_Frame_Roles_Update, L("UpdateRole"));
        roles.CreateChildPermission(PermissionNames.Pages_Frame_Roles_Delete, L("DeleteRole"));
        #endregion
    }
}

　　在設置完畢后，需要將該類集成到Core層/XXXCoreModule當前模塊中，才能使得該部分權限設置生效。

//配置權限管理
Configuration.Authorization.Providers.Add<SurroundAuthorizationProvider>();

 　　作為業務的入口，菜單是較為直觀的體現方式，現在可以，為菜單分配權限了，擁有權限的人才能看的到菜單，同時後台方法中也要有權限判定，菜單僅作為前端入口上的控制，權限判定作為後端的控制。在MVC層的Startup/XXXNavigationProvider.cs中完成菜單的配置工作，可以配置多級菜單，每個菜單可以配置相應的權限，在生成菜單判定時，如果父級菜單權限不足，則直接會跳過子級菜單的判定。

new MenuItemDefinition(//基礎支撐
    PageNames.FrameManage,
    L(PageNames.FrameManage),
    icon: "",
    requiredPermissionName: PermissionNames.Pages_Frame
).AddItem(
    new MenuItemDefinition(//組織機構
        PageNames.OrganizationUnits,
        L(PageNames.OrganizationUnits),
        url: "/OrganizationUnits",
        icon: "",
        requiredPermissionName: PermissionNames.Pages_Frame_OrganizationUnits
    )
).AddItem(
    new MenuItemDefinition(//用戶管理
        PageNames.Users,
        L(PageNames.Users),
        url: "/Users",
        icon: "",
        requiredPermissionName: PermissionNames.Pages_Frame_Users
    )
).AddItem(
    new MenuItemDefinition(//角色管理
        PageNames.Roles,
        L(PageNames.Roles),
        url: "/Roles",
        icon: "",
        requiredPermissionName: PermissionNames.Pages_Frame_Roles
    )
).AddItem(
    new MenuItemDefinition(//系統設置
        PageNames.HostSettings,
        L(PageNames.HostSettings),
        url: "/HostSettings",
        icon: "",
        requiredPermissionName: PermissionNames.Pages_Frame_HostSettings
    )
)

　　在前端頁面上，對於按鈕級別的控制也通過權限判定，Abp提供了判定方法，利用Razor語法進行按鈕控制

@if (await PermissionChecker.IsGrantedAsync(PermissionNames.Pages_Core_DataDictionary_Create))
{
    <button class="layui-btn layuiadmin-btn-dataDictionary" data-type="addDataDictionary">添加類型</button>
}

　　在後端方法上，通常我喜歡直接在應用服務中的方法上做權限判定(當然也可以前移到MVC層，但是這樣一來，針對於WebApi形式的Host層，又得多加一次判定了)，利用AbpAuthorize特性，判定該方法需要哪幾個權限才能訪問，而在mvc的控制器上做訪問認證。

[AbpAuthorize(PermissionNames.Pages_Core_DataDictionary_Create)]
private async Task CreateDataDictionaryAsync(CreateOrUpdateDataDictionaryInput input)
{

}

 

2、角色與權限

 　　在Abp中，角色信息存儲在abprole表中，角色與權限間的關聯存儲在abppermission這張表中，一個角色有多個權限，如果某個角色的權限被去掉了，這張表中的相關記錄將由abp負責刪除，我們只需要完成掌控哪些權限是這個角色有的就行。Abp中已經完成了角色的所有操作，但是前端部分採用的是bootstrap弄的，將其改造一波，成為layui風格。

　　

　　在創建角色中，主要是將選中的權限掛鈎到具體的某個角色上，該部分代碼沿用abp中自帶的角色權限處理方法。

private async Task CreateRole(CreateOrUpdateRoleInput input)
{
    var role = ObjectMapper.Map<Role>(input.Role);
    role.SetNormalizedName();

    CheckErrors(await _roleManager.CreateAsync(role));

    var grantedPermissions = PermissionManager
        .GetAllPermissions()
        .Where(p => input.PermissionNames.Contains(p.Name))
        .ToList();

    await _roleManager.SetGrantedPermissionsAsync(role, grantedPermissions);
}

　　指定角色Id，租戶Id及之前聲明的權限名稱，在abppermission中可查看到具體角色權限。

　　

 

3、用戶與角色

 　　一個用戶可以承擔多個角色，履行不同角色的義務，作為一個業務系統最基本的單元，abp中提供了這些概念並在Module Zero模塊中已經完成了對用戶的一系列操作，用戶信息存儲在AbpUsers表中,用戶直接關聯的角色保存在AbpUserRoles表中，abp中MVC版本採用的是bootstrap風格，因此，用layui風格完成一次替換，並且，改動一些頁面布局。

　　

　　Abp版本中，由於是土耳其大佬所開發的習慣，針對於姓和名做了拆分，因此對於我們的使用要做一次處理，我這先簡單處理了一下，並且在業務系統中，郵箱時有時無，因此也需要進行考慮。

[AbpAuthorize(PermissionNames.Pages_Frame_Users_Create)]
private async Task CreateUser(CreateOrUpdateUserInput input)
{
    var user = ObjectMapper.Map<User>(input.User);
    user.TenantId = AbpSession.TenantId;
    user.IsEmailConfirmed = true;
    user.Name = "Name";
    user.Surname = "Surname";
    //user.EmailAddress = string.Empty;

    await UserManager.InitializeOptionsAsync(AbpSession.TenantId);
    foreach (var validator in _passwordValidators)
    {
        CheckErrors(await validator.ValidateAsync(UserManager, user, AppConsts.DefaultPassword));
    }

    user.Password = _passwordHasher.HashPassword(user, AppConsts.DefaultPassword);

    await _userManager.InitializeOptionsAsync(AbpSession.TenantId);

    CheckErrors(await _userManager.CreateAsync(user, AppConsts.DefaultPassword));

    if (input.AssignedRoleNames != null)
    {
        CheckErrors(await _userManager.SetRoles(user, input.AssignedRoleNames));
    }

    if (input.OrganizationUnitIds != null)
    {
        await _userManager.SetOrganizationUnitsAsync(user, input.OrganizationUnitIds);
    }

    CurrentUnitOfWork.SaveChanges();
}

　　此處對用戶個人單獨的權限沒有去做處理，依照Abp的文檔有那麼一句話，大多數應用程序中，基於角色的已經足夠使用了，如果想聲明特定權限給用戶，那麼針對於用戶本身的角色權限則被覆蓋。 　　　

　

　至此，修改整合用戶、角色和權限加入到系統中初步完成了，至於一些更為豐富的功能，待逐步加入中，車子再好，司機也得睡覺。

 

　倉庫地址：

2019-11-17,望技術有成后能回來看見自己的腳步

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置，台北網頁設計，各種案例分享

幾個月前，我的任務是將我們組的 Vue.js 項目構建配置升級到 Webpack 4。我們的主要目標之一是利用 tree-shaking 的優勢，即 Webpack 去掉了實際上並沒有使用的代碼來減少包的大小。現在，tree-shaking 的好處將根據你的代碼庫而有所不同。由於我們的幾個架構決策，我們從公司內部的其他庫中提取了大量代碼，而我們只使用了其中的一小部分。

我寫這篇文章是因為恰當地優化 Webpack 並不簡單。一開始我以為這是一種簡單的魔法，但後來我花了一個月的時間在網上搜索我遇到的一系列問題的答案。我希望通過這篇文章，其他人會更容易地處理類似問題。

先說好處

在討論技術細節之前，讓我先總結一下好處。不同的應用程序將看到不同程度的好處。主要的決定因素是應用程序中死代碼的數量。如果你沒有多少死代碼，那麼你就看不到 tree-shaking 的多少好處。我們項目里有很多死代碼。

在我們部門，最大的問題是共享庫的數量。從簡單的自定義組件庫，到企業標準組件庫，再到莫名其妙地塞到一個庫中的大量代碼。很多都是技術債務，但一個大問題是我們所有的應用程序都在導入所有這些庫，而實際上每個應用程序都只需要其中的一小部分

總的來說，一旦實現了 tree-shaking，我們的應用程序就會根據應用程序的不同，縮減率從25%到75%。平均縮減率為52%，主要是由這些龐大的共享庫驅動的，它們是小型應用程序中的主要代碼。

同樣，具體情況會有所不同，但是如果你覺得你打的包中可能有很多不需要的代碼，這就是如何消除它們的方法。

沒有示例代碼倉庫

對不住了各位老鐵，我做的項目是公司的財產，所以我不能分享代碼到 GitHub 倉庫了。但是，我將在本文中提供簡化的代碼示例來說明我的觀點。

因此，廢話少說，讓我們來看看如何編寫可實現 tree-shaking 的最佳 webpack 4 配置。

什麼是死代碼

很簡單：就是 Webpack 沒看到你使用的代碼。Webpack 跟蹤整個應用程序的 import/export 語句，因此，如果它看到導入的東西最終沒有被使用，它會認為那是“死代碼”，並會對其進行 tree-shaking 。

死代碼並不總是那麼明確的。下面是一些死代碼和“活”代碼的例子，希望能讓你更明白。請記住，在某些情況下，Webpack 會將某些東西視為死代碼，儘管它實際上並不是。請參閱《副作用》一節，了解如何處理。

// 導入並賦值給 JavaScript 對象，然後在下面的代碼中被用到
// 這會被看作“活”代碼，不會做 tree-shaking
import Stuff from './stuff';
doSomething(Stuff);
// 導入並賦值給 JavaScript 對象，但在接下來的代碼里沒有用到
// 這就會被當做“死”代碼，會被 tree-shaking
import Stuff from './stuff';
doSomething();
// 導入但沒有賦值給 JavaScript 對象，也沒有在代碼里用到
// 這會被當做“死”代碼，會被 tree-shaking
import './stuff';
doSomething();
// 導入整個庫，但是沒有賦值給 JavaScript 對象，也沒有在代碼里用到
// 非常奇怪，這竟然被當做“活”代碼，因為 Webpack 對庫的導入和本地代碼導入的處理方式不同。
import 'my-lib';
doSomething();

用支持 tree-shaking 的方式寫 import

在編寫支持 tree-shaking 的代碼時，導入方式非常重要。你應該避免將整個庫導入到單個 JavaScript 對象中。當你這樣做時，你是在告訴 Webpack 你需要整個庫， Webpack 就不會搖它。

以流行的庫 Lodash 為例。一次導入整個庫是一個很大的錯誤，但是導入單個的模塊要好得多。當然，Lodash 還需要其他的步驟來做 tree-shaking，但這是個很好的起點。

// 全部導入 (不支持 tree-shaking)
import _ from 'lodash';
// 具名導入(支持 tree-shaking)
import { debounce } from 'lodash';
// 直接導入具體的模塊 (支持 tree-shaking)
import debounce from 'lodash/lib/debounce';

基本的 Webpack 配置

使用 Webpack 進行 tree-shaking 的第一步是編寫 Webpack 配置文件。你可以對你的 webpack 做很多自定義配置，但是如果你想要對代碼進行 tree-shaking，就需要以下幾項。

首先，你必須處於生產模式。Webpack 只有在壓縮代碼的時候會 tree-shaking，而這隻會發生在生產模式中。

其次，必須將優化選項 “usedExports” 設置為true。這意味着 Webpack 將識別出它認為沒有被使用的代碼，並在最初的打包步驟中給它做標記。

最後，你需要使用一個支持刪除死代碼的壓縮器。這種壓縮器將識別出 Webpack 是如何標記它認為沒有被使用的代碼，並將其剝離。TerserPlugin 支持這個功能，推薦使用。

下面是 Webpack 開啟 tree-shaking 的基本配置：

// Base Webpack Config for Tree Shaking
const config = {
 mode: 'production',
 optimization: {
  usedExports: true,
  minimizer: [
   new TerserPlugin({...})
  ]
 }
};

有什麼副作用

僅僅因為 Webpack 看不到一段正在使用的代碼，並不意味着它可以安全地進行 tree-shaking。有些模塊導入，只要被引入，就會對應用程序產生重要的影響。一個很好的例子就是全局樣式表，或者設置全局配置的JavaScript 文件。

Webpack 認為這樣的文件有“副作用”。具有副作用的文件不應該做 tree-shaking，因為這將破壞整個應用程序。Webpack 的設計者清楚地認識到不知道哪些文件有副作用的情況下打包代碼的風險，因此默認地將所有代碼視為有副作用。這可以保護你免於刪除必要的文件，但這意味着 Webpack 的默認行為實際上是不進行 tree-shaking。

幸運的是，我們可以配置我們的項目，告訴 Webpack 它是沒有副作用的，可以進行 tree-shaking。

如何告訴 Webpack 你的代碼無副作用

package.json 有一個特殊的屬性 sideEffects，就是為此而存在的。它有三個可能的值：

true 是默認值，如果不指定其他值的話。這意味着所有的文件都有副作用，也就是沒有一個文件可以 tree-shaking。

false 告訴 Webpack 沒有文件有副作用，所有文件都可以 tree-shaking。

第三個值 […] 是文件路徑數組。它告訴 webpack，除了數組中包含的文件外，你的任何文件都沒有副作用。因此，除了指定的文件之外，其他文件都可以安全地進行 tree-shaking。

每個項目都必須將 sideEffects 屬性設置為 false 或文件路徑數組。在我公司的工作中，我們的基本應用程序和我提到的所有共享庫都需要正確配置 sideEffects 標誌。

下面是 sideEffects 標誌的一些代碼示例。儘管有 JavaScript 註釋，但這是 JSON 代碼：

// 所有文件都有副作用，全都不可 tree-shaking
{
 "sideEffects": true
}
// 沒有文件有副作用，全都可以 tree-shaking
{
 "sideEffects": false
}
// 只有這些文件有副作用，所有其他文件都可以 tree-shaking，但會保留這些文件
{
 "sideEffects": [
  "./src/file1.js",
  "./src/file2.js"
 ]
}

全局 CSS 與副作用

首先，讓我們在這個上下文中定義全局 CSS。全局 CSS 是直接導入到 JavaScript 文件中的樣式表(可以是CSS、SCSS等)。它沒有被轉換成 CSS 模塊或任何類似的東西。基本上，import 語句是這樣的：

// 導入全局 CSS
import './MyStylesheet.css';

因此，如果你做了上面提到的副作用更改，那麼在運行 webpack 構建時，你將立即注意到一個棘手的問題。以上述方式導入的任何樣式表現在都將從輸出中刪除。這是因為這樣的導入被 webpack 視為死代碼，並被刪除。

幸運的是，有一個簡單的解決方案可以解決這個問題。Webpack 使用它的模塊規則系統來控制各種類型文件的加載。每種文件類型的每個規則都有自己的 sideEffects 標誌。這會覆蓋之前為匹配規則的文件設置的所有 sideEffects 標誌。

所以，為了保留全局 CSS 文件，我們只需要設置這個特殊的 sideEffects 標誌為 true，就像這樣:

// 全局 CSS 副作用規則相關的 Webpack 配置
const config = {
 module: {
  rules: [
   {
    test: /regex/,
    use: [loaders],
    sideEffects: true
   }
  ]
 } 
};

Webpack 的所有模塊規則上都有這個屬性。處理全局樣式表的規則必須用上它，包括但不限於 CSS/SCSS/LESS/等等。

什麼是模塊，模塊為什麼重要

現在我們開始進入秘境。表面上看，編譯出正確的模塊類型似乎是一個簡單的步驟，但是正如下面幾節將要解釋的，這是一個會導致許多複雜問題的領域。這是我花了很長時間才弄明白的部分。

首先，我們需要了解一下模塊。多年來，JavaScript 已經發展出了在文件之間以“模塊”的形式有效導入/導出代碼的能力。有許多不同的 JavaScript 模塊標準已經存在了多年，但是為了本文的目的，我們將重點關注兩個標準。一個是 “commonjs”，另一個是 “es2015”。下面是它們的代碼形式：

// Commonjs
const stuff = require('./stuff');
module.exports = stuff;

// es2015 
import stuff from './stuff';
export default stuff;

默認情況下，Babel 假定我們使用 es2015 模塊編寫代碼，並轉換 JavaScript 代碼以使用 commonjs 模塊。這樣做是為了與服務器端 JavaScript 庫的廣泛兼容性，這些 JavaScript 庫通常構建在 NodeJS 之上(NodeJS 只支持 commonjs 模塊)。但是，Webpack 不支持使用 commonjs 模塊來完成 tree-shaking。

現在，有一些插件(如 common-shake-plugin)聲稱可以讓 Webpack 有能力對 commonjs 模塊進行 tree-shaking，但根據我的經驗，這些插件要麼不起作用，要麼在 es2015 模塊上運行時，對 tree-shaking 的影響微乎其微。我不推薦這些插件。

因此，為了進行 tree-shaking，我們需要將代碼編譯到 es2015 模塊。

es2015 模塊 Babel 配置

據我所知，Babel 不支持將其他模塊系統編譯成 es2015 模塊。但是，如果你是前端開發人員，那麼你可能已經在使用 es2015 模塊編寫代碼了，因為這是全面推薦的方法。

因此，為了讓我們編譯的代碼使用 es2015 模塊，我們需要做的就是告訴 babel 不要管它們。為了實現這一點，我們只需將以下內容添加到我們的 babel.config.js 中(在本文中，你會看到我更喜歡JavaScript 配置而不是 JSON 配置)：

// es2015 模塊的基本 Babel 配置
const config = {
 presets: [
  [
   '[@babel/preset-env](http://twitter.com/babel/preset-env)',
   {
    modules: false
   }
  ]
 ]
};

把 modules 設置為 false，就是告訴 babel 不要編譯模塊代碼。這會讓 Babel 保留我們現有的 es2015 import/export 語句。

划重點：所有可需要 tree-shaking 的代碼必須以這種方式編譯。因此，如果你有要導入的庫，則必須將這些庫編譯為 es2015 模塊以便進行 tree-shaking 。如果它們被編譯為 commonjs，那麼它們就不能做 tree-shaking ，並且將會被打包進你的應用程序中。許多庫支持部分導入，lodash 就是一個很好的例子，它本身是 commonjs 模塊，但是它有一個 lodash-es 版本，用的是 es2015模塊。

此外，如果你在應用程序中使用內部庫，也必須使用 es2015 模塊編譯。為了減少應用程序包的大小，必須將所有這些內部庫修改為以這種方式編譯。

不好意思， Jest 罷工了

其他測試框架情況類似，我們用的是 Jest。

不管怎麼樣，如果你走到了這一步，你會發現 Jest 測試開始失敗了。你會像我當時一樣，看到日誌里出現各種奇怪的錯誤，慌的一批。別慌，我會帶你一步一步解決。

出現這個結果的原因很簡單：NodeJS。Jest 是基於 NodeJS 開發的，而 NodeJS 不支持 es2015 模塊。為此有一些方法可以配置 Node，但是在 jest 上行不通。因此，我們卡在這裏了：Webpack 需要 es2015 進行 tree shaking，但是 Jest 無法在這些模塊上執行測試。

就是為什麼我說進入了模塊系統的“秘境”。這是整個過程中耗費我最多時間來搞清楚的部分。建議你仔細閱讀這一節和後面幾節，因為我會給出解決方案。

解決方案有兩個主要部分。第一部分針對項目本身的代碼，也就是跑測試的代碼。這部分比較容易。第二部分針對庫代碼，也就是來自其他項目，被編譯成 es2015 模塊並引入到當前項目的代碼。這部分比較複雜。

解決項目本地 Jest 代碼

針對我們的問題，babel 有一個很有用的特性：環境選項。通過配置可以運行在不同環境。在這裏，開發和生產環境我們需要 es2015 模塊，而測試環境需要 commonjs 模塊。還好，Babel 配置起來非常容易：

// 分環境配置Babel 
const config = {
 env: {
  development: {
   presets: [
    [
     '[@babel/preset-env](http://twitter.com/babel/preset-env)',
     {
      modules: false
     }
    ]
   ]
  },
  production: {
   presets: [
    [
     '[@babel/preset-env](http://twitter.com/babel/preset-env)',
     {
      modules: false
     }
    ]
   ]
  },
  test: {
   presets: [
    [
     '[@babel/preset-env](http://twitter.com/babel/preset-env)',
     {
      modules: 'commonjs'
     }
    ]
   ],
   plugins: [
    'transform-es2015-modules-commonjs' // Not sure this is required, but I had added it anyway
   ]
  }
 }
};

設置好之後，所有的項目本地代碼能夠正常編譯，Jest 測試能運行了。但是，使用 es2015 模塊的第三方庫代碼依然不能運行。

解決 Jest 中的庫代碼

庫代碼運行出錯的原因非常明顯，看一眼node_modules 目錄就明白了。這裏的庫代碼用的是 es2015 模塊語法，為了進行 tree-shaking。這些庫已經採用這種方式編譯過了，因此當 Jest 在單元測試中試圖讀取這些代碼時，就炸了。注意到沒有，我們已經讓 Babel 在測試環境中啟用 commonjs 模塊了呀，為什麼對這些庫不起作用呢？這是因為，Jest (尤其是 babel-jest) 在跑測試之前編譯代碼的時候，默認忽略任何來自node_modules 的代碼。

這實際上是件好事。如果 Jest 需要重新編譯所有庫的話，將會大大增加測試處理時間。然而，雖然我們不想讓它重新編譯所有代碼，但我們希望它重新編譯使用 es2015 模塊的庫，這樣才能在單元測試里使用。

幸好，Jest 在它的配置中為我們提供了解決方案。我想說，這部分確實讓我想了很久，並且我感覺沒必要搞得這麼複雜，但這是我能想到的唯一解決方案。

配置 Jest 重新編譯庫代碼

// 重新編譯庫代碼的 Jest 配置 
const path = require('path');
const librariesToRecompile = [
 'Library1',
 'Library2'
].join('|');
const config = {
 transformIgnorePatterns: [
  `[\\\/]node_modules[\\\/](?!(${librariesToRecompile})).*$`
 ],
 transform: {
  '^.+\.jsx?$': path.resolve(__dirname, 'transformer.js')
 }
};

以上配置是 Jest 重新編譯你的庫所需要的。有兩個主要部分，我會一一解釋。

transformIgnorePatterns 是 Jest 配置的一個功能，它是一個正則字符串數組。任何匹配這些正則表達式的代碼，都不會被 babel-jest 重新編譯。默認是一個字符串“node_modules”。這就是為什麼Jest 不會重新編譯任何庫代碼。

當我們提供了自定義配置，就是告訴 Jest 重新編譯的時候如何忽略代碼。也就是為什麼你剛才看到的變態的正則表達式有一個負向先行斷言在裏面，目的是為了匹配除了庫以外的所有代碼。換句話說，我們告訴 Jest 忽略 node_modules 中除了指定庫之外的所有代碼。

這又一次證明了 JavaScript 配置比 JSON 配置要好，因為我可以輕鬆地通過字符串操作，往正則表達式里插入庫名字的數組拼接。

第二個是 transform 配置，他指向一個自定義的 babel-jest 轉換器。我不敢100%確定這個是必須的，但我還是加上了。設置它用於在重新編譯所有代碼時加載我們的 Babel 配置。

// Babel-Jest 轉換器
const babelJest = require('babel-jest');
const path = require('path');
const cwd = process.cwd();
const babelConfig = require(path.resolve(cwd, 'babel.config'));
module.exports = babelJest.createTransformer(babelConfig);

這些都配置好后，你在測試代碼應該又能跑了。記住了，任何使用庫的 es2015 模塊都需要這樣配置，不然測試代碼跑不動。

Npm/Yarn Link 就是魔鬼

接下來輪到另一個痛點了：鏈接庫。使用 npm/yarn 鏈接的過程就是創建一個指向本地項目目錄的符號鏈接。結果表明，Babel 在重新編譯通過這種方式鏈接的庫時，會拋出很多錯誤。我之所以花了這麼長時間才弄清楚 Jest 這檔子事兒，原因之一就是我一直通過這種方式鏈接我的庫，出現了一堆錯誤。

解決辦法就是：不要使用 npm/yarn link。用類似 “yalc” 這樣的工具，它可以連接本地項目，同時能模擬正常的 npm 安裝過程。它不但沒有 Babel 重編譯的問題，還能更好地處理傳遞性依賴。

針對特定庫的優化。

如果完成了以上所有步驟，你的應用基本上實現了比較健壯的 tree shaking。不過，為了進一步減少文件包大小，你還可以做一些事情。我會列舉一些特定庫的優化方法，但這絕對不是全部。它尤其能為我們提供靈感，做出一些更酷的事情。

MomentJS 是出了名的大體積庫。幸好它可以剔除多語言包來減少體積。在下面的代碼示例中，我排除了 momentjs 所有的多語言包，只保留了基本部分，體積明顯小了很多。

// 用 IgnorePlugin 移除多語言包
const { IgnorePlugin } from 'webpack';
const config = {
 plugins: [
  new IgnorePlugin(/^\.\/locale$/, /moment/)
 ]
};

Moment-Timezone 是 MomentJS 的老表，也是個大塊頭。它的體積基本上是一個帶有時區信息的超大 JSON 文件導致的。我發現只要保留本世紀的年份數據，就可以將體積縮小90%。這種情況需要用到一個特殊的 Webpack 插件。

// MomentTimezone Webpack Plugin
const MomentTimezoneDataPlugin = require('moment-timezone-data-webpack-plugin');
const config = {
 plugins: [
  new MomentTimezoneDataPlugin({
   startYear: 2018,
   endYear: 2100
  })
 ]
};

Lodash 是另一個導致文件包膨脹的大塊頭。幸好有一個替代包 Lodash-es，它被編譯成 es2015 模塊，並帶有 sideEffects 標誌。用它替換 Lodash 可以進一步縮減包的大小。

另外，Lodash-es，react-bootstrap 以及其他庫可以在 Babel transform imports 插件的幫助下實現瘦身。該插件從庫的 index.js 文件讀取 import 語句，並使其指向庫中特定文件。這樣就使 webpack 在解析模塊樹時更容易對庫做 tree shaking。下面的例子演示了它是如何工作的。

// Babel Transform Imports
// Babel config
const config = {
 plugins: [
  [
   'transform-imports',
   {
    'lodash-es': {
     transform: 'lodash/${member}',
     preventFullImport: true
    },
    'react-bootstrap': {
     transform: 'react-bootstrap/es/${member}', // The es folder contains es2015 module versions of the files
     preventFullImport: true
    }
   }
  ]
 ]
};
// 這些庫不再支持全量導入，否則會報錯
import _ from 'lodash-es';
// 具名導入依然支持
import { debounce } from 'loash-es';
// 不過這些具名導入會被babel編譯成這樣子
// import debounce from 'lodash-es/debounce';

總結

全文到此結束。這樣的優化可以極大地縮減打包后的大小。隨着前端架構開始有了新的方向（比如微前端），保持包大小最優化變得比以往更加重要。希望本文能給那些正在給應用程序做tree shaking的同學帶來一些幫助。

交流

歡迎掃碼關注微信公眾號“1024譯站”，為你奉上更多技術乾貨。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置，台北網頁設計，各種案例分享