在業務系統需求規劃過程中，通常對於諸如組織機構、用戶和角色等這種基礎功能，通常是將這部分功能規劃到通用子域中，這也說明了，對於這部分功能來講，是系統的基石，整個業務體系是建立於這部分基石之上的，當然，還有諸如多語言、設置管理、認證和授權等。對於這部分功能，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地圖已可更新顯示潭子電動車充電站設置地點!!

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

如何實現類似於Jumpserver koko一樣的終端錄製回放功能呢？本文介紹一個神器

asciinema 是一款開源免費的終端錄製工具，它可以將命令行輸入輸出的任何內容加上時間保存在文件中，同時還提供方法在終端或者web瀏覽器中進行回放

asciinema的錄製和播放都是基於文本的，相比傳統的video有很多好處，例如錄製文件體積小，在播放的過程中可以暫停複製其中的文本內容等等

同時asciinema還提供了一個網站，你如果願意還可以將錄製的內容上傳至進行展示，也可以在這裏找到很多有趣的終端錄像

asciinema由以下三個子項目構成：

1. asciinema：基於命令行的終端會話記錄器
2. asciinema.org：提供API供上傳錄像和展示的網站
3. javascript player：用於在web上播放錄像的js播放器

asciinema的安裝和使用都非常簡單，一起來看看吧

安裝

asciinema為python開發，可以直接通過apt-get、yum或者pip進行安裝

# apt-get install asciinema

安裝完成后查看版本

# asciinema --version
asciinema 2.0.2

asciinema有v1和v2兩個版本，差異較大，咖啡君使用了v2，以下所有內容也基於v2演示

asciinema有5個參數，分別為錄製：rec，播放：play，以文件形式查看錄製內容：cat，上傳文件到asciinema.org網站：upload、asciinema.org賬號認證：auth，本文主要說明rec和play的使用

錄製

# asciinema rec ops-coffee.cast

有幾個參數可以使用：

--stdin 表示啟用標準輸入錄製，意思是通常情況下linux輸入密碼類的信息都不會显示，如果開啟了這個選項，可以記錄鍵盤輸出的密碼，但這個功能官方似乎還沒有支持，加了后看不到效果

--append 添加錄製到已存在的文件中

--raw 保存原始STDOUT輸出，無需定時信息等

--overwrite 如果文件已存在，則覆蓋

-c 要記錄的命令，默認為$SHELL

-e 要捕獲的環境變量列表，默認為SHELL,TERM

-t 後跟数字，指定錄像的title

-i 後跟数字，設置錄製時記錄的最大空閑時間

-y 所有提示都輸入yes

-q 靜默模式，加了此參數在進入錄製或者退出錄製時都沒有提示

輸入exit或按ctrl+D組合鍵退出錄製

播放

# asciinema play ops-coffee.cast 

有兩個參數可以使用：

-s 後邊跟数字，表示用幾倍的速度來播放錄像

-i 後邊跟数字，表示在播放錄像時空閑時間的最大秒數

在播放的過程中你可以通過空格來控制暫停或播放，也可以通過ctrl+c組合鍵來退出播放，當你按空格鍵暫停時，可以通過.號來逐幀显示接下來要播放的內容

文件

asciinema推薦的文件後綴是.cast，當然linux是不關心文件後綴的，你用什麼都可以，推薦按規範使用.cast，文件內容大概如下

# cat ops-coffee.cast
{"version": 2, "width": 237, "height": 55, "timestamp": 1572646909, "env": {"SHELL": "/bin/bash", "TERM": "linux"}, "title": "ops-coffee"}
[0.010014, "o", "root@onlinegame:~# "]
[1.296458, "o", "exit"]
[1.976439, "o", "\r\n"]
[1.976532, "o", "exit\r\n"]

cast文件主要有兩部分組成，位於第一行的一個字典，這裏叫header

{
    "version": 2,
    "width": 237,
    "height": 55,
    "timestamp": 1572646909,
    "env": {
        "SHELL": "/bin/bash",
        "TERM": "linux"
    },
    "title": "ops-coffee"
}

header很簡單，字段的意思分別為：version版本，width和height分別表示錄製窗口的寬高，timestamp錄製開始的時間戳，env錄製時指定的-e參數設置，title錄製時指定的-t參數設置

接下來的都是固定格式的內容，實際上就是IO流信息

[0.010014, "o", "root@onlinegame:~# "]

每一行都是由三部分組成的一個列表

第一部分為一個浮點數，表示輸入輸出這一行內容所花的時間

第二部分似乎是一個固定的字符串，沒有找到說明做什麼用的

第三部分就是具體的輸入輸出的內容

這個文件格式設計還是非常優雅的，開頭header聲明，後邊具體內容，如果中途因為任何意外導致錄像終止，也不會丟失整個錄像，而且還可以append增加錄像，這在需要長時間暫停錄製時非常有用，更重要的是可以流式讀取，幾乎很少佔用內存，不需要把整個錄像文件都放在內存中，對長時間的錄製播放更友好

自動錄製審計日誌

如果你有經歷過嚴格的IT審計，或者有用到堡壘機，就會知道操作過程是需要記錄並加入審計的，如果你有因為不知道是誰操作了什麼導致了數據被刪而背鍋的經歷，就會知道對操作過程的記錄有多麼的重要，接下來以一個簡單的案例來介紹asciinema有什麼樣的實用價值

如果希望能夠將linux服務器上devuser的所有操作過程都記錄下來，以備後續審計使用，該如何實現呢？

非常簡單，只需要在devuser用戶的家目錄下添加.bash_profile文件即可，內容如下：

$ cat ~/.bash_profile 
export LC_ALL=en_US.UTF-8
/usr/local/bin/asciinema rec /tmp/$USER-$(date +%Y%m%d%H%M%S).log -q

添加export LC_ALL=en_US.UTF-8的原因是有可能系統會報錯asciinema needs a UTF-8 native locale to run. Check the output of locale command.

rec命令進行錄製時添加了-q參數，這樣在進入或者退出時都不會有任何關於asciinema的提示，使用簡單方便

這樣devuser用戶每次登陸就會自動開啟一個錄像，如果需要審計或檢查操作，只需要回放錄像就可以了

你可能會說history命令一樣可以記錄用戶操作，asciinema有什麼優勢呢？asciinema不僅可以記錄用戶的輸入，還可以記錄系統的輸出，也就是說history只能記錄執行的命令，而asciinema還可以記錄執行的結果，怎麼樣，是不是很方便，趕緊試試吧

相關文章推薦閱讀：

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

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

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

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

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

※小三通物流營運型態?

※快速運回,大陸空運推薦?

本文是「vangoleo的Go語言學習筆記」系列文章之一。
官網:

往期回顧:

上一篇文章中，我們在Golang Playground中體驗了Go語言，編寫並運行了一個簡單的Hello World，相信大家對Go語言的語法有了一些了解。

學習一種編程語言，除了基本的語法，更重要的是要了解如何在實際的工程中使用它。本文中，我會和大家一起，從零開始，安裝Go語言，配置環境，安裝IDE，開發一個Hello World程序。這個Hello World版我會編寫兩個版本：GOPATH和Go Module版本。

Q:
本教程為什麼會編寫兩個版本？
A:
網上大部分Go語言Hello World都只簡單地介紹了GOPATH版本。但是從Go的1.11版本之後，已不再推薦使用GOPATH來構建應用了。也就是說GOPATH被認為是廢棄的，錯誤的做法。
正確的做法是使用Go Module。所以，有必要在教程中將這個信息告訴初學者，引導大家使用推薦的最佳實踐方式Go Module。
或許這也是本Hello World教程和網上大部分教程的區別吧。會從開發者的實際使用出發。介紹Go語言的發展歷史和最佳實踐。

安裝Go

使用Go語言開發，第一步肯定是安裝Go啦。

第一步：進入Go語言的官網https://golang.org。點擊“Download Go”。是的，就是那個傻傻的土撥鼠^_^

第二步：根據操作系統下載對應的軟件包進行安裝。
Golang對主流的操作系統都有支持，比如Windows，MacOS和Linux等。
本系列教程中，我會使用MacOS操作系統，所以選擇下載“Apple macOS”。大家要根據自己的操作系統進行下載。

第三步：安裝Go。
在MacOS下安裝Go很簡單，就是標準的DMG文件安裝，直接“下一步”就可以了。
第四步：確認Go是否安裝成功。
運行命令“go version”，會輸出類似於“go version go1.12.9 darwin/amd64”的內容。請確保包沒有任何錯誤發生。

配置環境

和其他開發語言類似，安裝了Go之後，還需要對開發環境進行相應的配置。比如在Java中，需要配置JAVA_HOME，MAVEN等。
Go開發相關的環境變量如下：

• GOROOT：GOROOT就是Go的安裝目錄。
• GOPATH：GOPATH保存go項目代碼。

GOROOT

GOROOT是Go的安裝路徑。Mac中安裝Go會自動配置好GOROOT，路徑為/usr/local/go。GOROOT在絕大多數情況下都不需要修改。以下是GOROOT目錄的內容(已省略了一些無關信息)：

tree -L 2 /usr/local/go

./
├── bin
│   ├── go
│   └── gofmt
├── doc
│   ├── articles
│   └── docs.html
├── src
│   ├── errors
│   ├── fmt
│   ├── log
│   └── os

可以看到GOROOT下有bin，doc和src目錄。bin目錄下有我們熟悉的go和gofmt工具。可以認為GOOROOT和Java里的JDK目錄類似。

GOPATH

GOPATH是開發時的工作目錄。用於：

• 保存編譯后的二進制文件。
• go get和go install命令會下載go代碼到GOPATH。
• import包時的搜索路徑。

關於GOPATH需要特別注意。在GO的1.11版本之前，GOPATH是必需的，且所有的Go項目代碼都要保存在GOPATH目錄下。Go的1.11版本之後，GO官方引入了Go Module。使用Go Module管理的項目可以放在GOPATH目錄外面。

使用GOPATH時，GO會在以下目錄中搜索包：

1. GOROOT/src：該目錄保存了Go標準庫代碼。
2. GOPATH/src：該目錄保存了應用自身的代碼和第三方依賴的代碼。

假設程序中引入了如下的包：

import "github.com/tom/hello-go/foo/bar"

第一步：Go會先去GOROOT的scr目錄中查找，很顯然它不是標準庫的包，沒找到。
第二步：繼續在GOPATH的src目錄去找，準確說是GOPATH/src/github.com/tom/hello-go/foo/bar這個目錄。如果該目錄不存在，會報錯找不到package。在使用GOPATH管理項目時，需要按照GO尋找package的規範來合理地保存和組織Go代碼。

Go的這個“將所有代碼都放置在GOPATH中”的設計，的確是和其他主流語言很不一樣。不管Go官方是出於什麼考慮，這個設計在實際使用中，的確給開發者造成了很大的不便和理解上的困難。甚至直接勸退了很多Go的初學者。
萬幸的是，Go Module正式發布了。Go Module的發布解決了困擾Go語言長達十年的代碼組織，依賴管理問題。

說明：關於GOPATH和Go Module的歷史淵源，詳細使用，會在另一篇進行說明。本文還是聚焦在Hello World入門。

另外，由於某些原因，Go的某些託管在Google倉庫中的代碼在國內是無法訪問的。如果使用Go Module，我們可以設置GOPROXY，讓Go從GOPROXY下載Go代碼，速度更快。國內用戶可以設置GOPROXY為，使用如下命令來設置GOPROXY：

export GOPROXY=https://goproxy.cn

關於環境配置，總結下來就是:

• 如果使用Go Module(推薦的)，設置export GOPROXY=。
• 如果使用GOPATH(遺留的，被廢棄的)，需要設置GOPATH到本地的某個目錄。

安裝IDE

目前比較常用的IDE有：

• Visual Studio Code
• GoLand

Visual Studio Code是微軟開發的一款開源的，輕量級的文本編輯器。通過安裝Go插件，可以用於Go語言的開發。GoLand是JetBrains公司開發的，專業的Go語言開發IDE。

推薦使用GoLand。很多人都說Visual Studio Code更輕量級，但作為一款每天都要重度使用的，需要靠它吃飯的工具，我們需要的是功能全面。尤其是當你需要完備的調試，需要強大的IDE智能輔助功能時，相信你會選擇更專業的GoLand。

GoLand的官方主頁為https://www.jetbrains.com/go/，點擊“Download”即可下載

注意
GoLand使用的是和IntelliJ IDEA一樣的框架，是用Java語言開發的。你需要安裝Java環境才可以運行GoLand哦。

GoLand是收費軟件，只有30天的試用期。試用期結束后，需要購買授權。當然在天朝，我們都習慣不花錢用軟件。大家可以自行百度或google搜索一下。

Hello World(GOPATH版)

第一步：設置GOPATH
首先設置GOPATH，假設GOPATH設置為$HOME/worspace/go。
第二步：創建子目錄
進入$HOME/workspace/go目錄。新建子目錄src。然後再src中新建子目錄hello。在hello目錄，新建一個hello-world.go文件：
目錄結構應該如下所示：

$HOME
  workspace
    go
      src
        hello
          hello-world.go

第三步：創建hello-world.go文件：

package main
import "fmt"
func main() {
    fmt.Println("hello world")
}

第四步：執行go build
在$HOME/workspace/go目錄執行命令：

go build

會生成一個可執行二進制文件：hello。如果是Windows系統，會生成hello.exe文件。
第五步：運行hello文件：

./hello

hello world

輸出“hello world”。

Hello World(GO Module版)

第一步：創建項目的根目錄
任意創建一個目錄(可以不在GOPATH中)，假設是$HOME/tmp/hello。
第二步：初始化Go模塊
執行命令：

go mod init github.com/vangoleo/hello

該命令會將hello目錄初始化為一個Go module，並生成一個$HOME/tmp/hello/go.mod文件。內容如下：

module github.com/vangoleo/hello

go 1.12

第三步：編寫hello.go文件
編寫文件$HOME/tmp/hello/hello.go:

package main

import (
    "fmt"
    "rsc.io/quote"
)

func main() {
    fmt.Println(quote.Hello())
}

第四步：編輯go.mod文件：
在實際項目中，都會使用到第三方庫。可以在Go Module中添加項目的依賴。本例中，我們會添加一個quote依賴，該依賴會打印當前語言的“Hello World”，比如，如果是中文環境，會打印“你好，世界”。
編輯go.mod文件，添加quote依賴：

module github.com/vangoleo/hello

go 1.12

require rsc.io/quote v1.5.2

第五步：執行go build
執行go build，會生成可執行文件$HOME/tmp/hello/hello。
第六步：執行hello文件
執行hello文件，輸出“你好，世界”。

最後

本文中，我們從下載安裝，配置Go環境開始，並完成了GOPATH和Go Module兩個版本的Hello World應用。如果你跟着我一步一步完成了這些步驟，恭喜你！！！已經完成了第一個真正的Go應用，並且使用了正確的Go Module來管理Go程序。

接下來，我們可以開始學習Go語言的語法部分(基本數據類型，判斷，循環等)了。咋們下期見。

本文由 發布

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

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

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

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

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

※小三通物流營運型態?

※快速運回,大陸空運推薦?