JavaScript社會欠一份情其編譯器維護者。收斂到一個共同的ECMA語言實現,我們可以使用巴別塔介紹語言特性之前有時間烤在每個瀏覽器引擎或JS運行時。此外,解析器,這些編譯器為我們提供一個合理的力量抽象語法樹(AST),也就是一個表示的代碼作為一個對象圖更好地理解我們的代碼和創建有用的工具。
ast是不小的祝福任何人使用JavaScript。他們給我們能力視圖代碼結構化數據,而不是純文本需要出租汽車司機正則表達式和神秘的grep旗幟來解釋。這種理解代碼的能力,很容易把它能感覺到接近魔法……和even the simplest transforms will make you feel like some kind of software wizard. At Braze, we use the static code analysis tool ESLint, which leverages ASTs, to make our development experience better—so let’s explore how we’re using it and how you, too, can utilize and customize your ESLint rules.
產品毛羽:沒有那麼抽象ast的好處之一
每個開發人員工具包都需要一個好的linter-one的許多工具使用的抽象語法樹以及獲取它們的力量ESLint近年來出現的嗎事實上的對JavaScript和靜態代碼檢查器打印稿。結合導向鉤子,產品毛羽成為寶貴的發展經驗的一部分通過執行基本文體的規則和約定。我將危害安裝巴別塔的猜想preset-env將覆蓋約80%的你的需要,你可以祝賀自己美好的一天的工作後安裝和修複錯誤。有一個揮之不去的20%大量的插件和規則集供您使用,還發明了規則規定適合您的組織的需要。
為了說明這一點,下麵是一個具體的挑戰我們在釺:我們寫很多集成測試測試部分主要web SDK和REST API。
釺平台構建支持響應客戶信息,所以這些測試通常包括觸發或運動帆布發送,然後查詢統計數據維護,結果發生了一件事。我們確定這些活動或畫布api使用一個全局唯一標識符(GUID),在我們的測試是這樣的:
這些測試通常不完整的失敗,我們可以熟睡知道畫布會嗡嗡作響的每天數以百萬計的正確發送消息。但是當他們做失敗,我們嚐試的差距來診斷問題並盡快撲滅火焰。(注意,放心,親愛的讀者,我們隻運行這些測試在我們的登台環境推動生產之前我們烤的代碼)。
當有故障,我們跟蹤它回到測試和尋找潛在的GUID (s)測試對象(年代)。在銅焊,我們自己的忠實粉絲,所以我們會檢查該對象的數據在我們的麵向客戶的儀表板應用程序並驗證它的正確配置。出於這個原因,在儀表板中嵌入一個硬鏈接的對象測試評論是很重要的;事實證明,大多數集成開發環境(ide)很擅長識別url,所以工程師診斷失敗是一次點擊遠離重要信息。
我們結構這些注釋JSDoc評論如下:
當我們選定了這個約定,我們下一個合乎邏輯的步驟編寫一個定製的ESLint規則檢查guid應用適當的注釋,然後其餘的代碼庫。
這是我們如何做的隻有五個簡單的步驟:
1。弄清楚你想要做什麼
在這種情況下,我們正在尋找任何類型的變量聲明也類似一個GUID分配一個字符串。我們也發現了一些情況聲明一個變量,但是GUID被分配在別處,所以我們一直記住當我們進入第二步……
2。找出AST看起來像一些代碼
其他工具AST探索,我無法推薦astexplorer.net當涉及到這一步。隻是粘貼一些代碼,選擇你需要的解析器(在開發eslint規則,選擇espree),看看輸出是:
如步驟1中所述,有兩種方法來表達一個GUID任務。鑒於此,我們注意到節點類型和相關的屬性。
4所示。告訴ESLint怎麼了
我們確認相關節點後,我們使用了上下文參數報告。評論不是espree返回的AST的一部分,所以你必須使用一個特殊函數為了得到評論相鄰節點。最重要的是,這些上下文。報告對象實際上就是告訴ESLint打印錯誤。鑒於評論和他們的物質,我們寫了一些簡單的命令邏輯調用context.report左右:
在那之後,我們連線reportComments對於每個節點類型,占每個不同的形狀:
注意這個名字是如何的不同參數為該節點引用類型:
5。連接您的規則兜風
最後,我們添加了全新的規則.eslintrc配置和確認我們的規則生活,增加這些旗幟npm運行線頭命令,運行它,我們看到了大量的錯誤需要修正:
因為這需要一些開發人員幹預,我們不能添加邏輯自動修複的評論,但可以定義,行為規則運行時ESLint——修複國旗。
最終的想法(如果你讀過這麼遠,恭喜你!你現在明白~ 80% ESLint如何工作!)
希望這個具體例子突顯出,粗體,和選擇的觀點代碼是結構化數據。如果您編寫代碼時,您正在設計一個工件在每一行並將深思熟慮的心思,這審議和護理隻能提高了優越的工具。
隨著我們繼續寫更多的集成測試在釺,我們發現我們有一個更容易通過自動化執行約定,確保與測試套件的互動仍然是一個愉快的經曆。沒有工具來確保所有guid是注釋,我們的生活將會明顯更糟的是,因為額外的時間來調試測試。
事實上,這種延遲可能幾秒鍾的時間,可能已經使用emoji-reacting Slack-but仍然貓gif,考慮有多少你當前的發展經驗是建立在這些交互工具然後思考如何優化每一個可以節省時間和精力。
感興趣學習更多關於釺也許加入我們的團隊?看看我們的工作頁麵。
