大多數庫和架構都配備有一個
，通過輸入一個指令，可以為我們啟動一些架構項目，以快速建立我希望的東西。這通常包括一個啟動腳本（有時用自動重新加載器），建構腳本，測試結構等等。當我們建立新項目時，這些工具可以減輕我們大量備援檔案的編寫。讓我們來看看更多其他的一些指令行工具。
Webpack 配置
配置你的 webpack 建構過程并真正了解你在做什麼，可能是 2017 年更令人畏懼的學習曲線之一。幸運的是，他們的核心貢獻者之一
Sean Larkin奔走在世界各地，為我們提供了
很棒的演講和
非常有趣和有用的教程。
現在許多架構不僅為您建立了 webpack 配置檔案，甚至将它們填充到您甚至可能不需要看的地步。
Vue 的 CLI 工具有一個
webpack 專用的模闆，為您提供全功能的 Webpack 設定。為了讓您充分了解指令行工具提供的内容，以下是 Vue CLI 模闆包含的内容：
- npm run dev: 首要開發體驗
- 用于 Vue 單檔案元件的 Webpack + vue-loader
- 熱更新中的狀态保持
- 編譯錯誤時的狀态保持
- 儲存時使用 ESLint 檢查
- 源檔案映射（Source Map）
- npm run build: 為生産環境準備好建構
- 使用 UglifyJS v3 最小化 JavaScript
- html-minifier 最小化 HTML
- cssnano 提取所有元件中的 CSS 并最小化
- 對靜态資源計算 Hash 使之在緩存中長期有效，并自動為生産環境生成使用這些靜态資源 URL 的 index.html
- 使用 npm run build --report 建構并生成含有流量分析的報告
- npm run unit: 使用 Jest 在 JSDOM 中運作單元測試，或者在 PhantomJS 中使用 Karma + Mocha + karma-webpack
- 測試檔案支援 ES2015+
- 簡單打樁
- npm run e2e: 使用 Nightwatch 進行端到端測試
- 自動處理 Selenium 和 chromedriver 依賴
- 自動生成 Selenium 伺服器
- 在多個浏覽器中并行地運作測試
- 使用一個非常好的指令行工具：
，從另一個方面支援着 Webpack 的功能。如果你需要自定義 webpack 配置，隻需要建立 preact.config.js，它導出一個函數來改變 webpack。大量的工具帶來了大量的便捷性，開發人員們也在互相幫助。
Babel：啟用還是關閉
弄明白了嗎？Babel 聽起來像巴比倫(Babylon)。我都快崩潰了。我并沒有試圖将 Babel 與 Babylon 聯系在一起，但有人
說過我們可能會放棄對轉譯(transpiling)的依賴。在過去幾年裡，Babel 一直是個大問題，因為我們想要 ECMAScript 提出的所有美好的特性，但又并不想等待浏覽器跟上更新。随着 ECMAScript 轉向年度小版本釋出，浏覽器可能會跟上。剔除一些非常棒的
kangax相容性圖表的 JavaScript 釋出是什麼樣的呢？
這些圖表的截圖不是很清晰，因為我想展示它們看起來是多麼的綠！更多有關詳細資訊，請單擊圖像下方的連結以進一步檢視圖表。
在第一張圖中，左側的紅色塊是編譯器（例如es-6 shim，Closure等）和較舊的浏覽器（例如Kong 4.14和IE 11）。右邊的五個紅色列是伺服器/編譯器PJS、JXA、Node 4、DUK 1.8和DUK 2.2。在較低的圖上，看起來像一隻狗并且亂七八糟的感歎号的糟糕圖形的紅色區域是僅使用Node 6.5+具有綠色條紋的伺服器/運作時。左邊紅色方塊的構成是編譯器/polyfils和IE 11。更重要的是，看看那些綠的！在最流行的浏覽器中，我們幾乎都是綠色的。2017年功能中的唯一紅色标記是Firefox 52 ESR for Shared Memory和Atomics。
從一些角度來看，這裡是來自
維基百科的一些浏覽器使用情況。
好的，關閉Babel可能會有點麻煩，因為當它落實之時，我們希望其能被盡可能多的使用者盡可能地通路Babel。想想下我們可能能夠擺脫那個額外的步驟，在我們沒有使用轉譯器之時。
翻譯于 5個月前
1人頂
頂翻譯得不錯哦！
談談 TypeScript
如果我們在談 JavaScript，那就不得不談談
TypeScript。5 年前從微軟辦公室誕生的 TypeScript 發展到 2017 年，已經非常酷了。幾乎沒有什麼會議在談論“我們為什麼喜歡 TypeScript”，但它為開發帶來了新的體驗，自然受到人們喜歡。對于 TypeScript，不需要贊美，我們隻是談談開發者在使用它的時候為什麼會感到輕松。
對于想在 JavaScript 中使用類型的人來說，TypeScript 在文法上是 JavaScript 的超集，為其帶來了靜态類型。如果你喜歡這種東西，就會覺得非常酷。當然，如果你看到了
JavaScript 狀态調查的最新結果，你會發現實際上很多人都喜歡。
來自
JavaScript 的狀态我們看看 Brian Terlson 是怎麼說的：
作為 2014 年為 JavaScript 提議加入類型的人，我不認為類型會在較短時間内實作。從标準的角度來說，這是一個極其複雜的問題。對于TypeScript 使用者來說，采用 TypeScript 标準當然無可非議，不過也有其它一些J avaScript 超集支援類型，它們支援着一些相當重要的用法，比如 Closure Compiler 和 FLow。這些工具的行為各不相同，甚至不清楚它們是否存在一個共同的子集（我不認為有直覺的表現）。我不确定類型标準更像哪一個，我和其他人會繼續進行相關的調查研究，這可能是有意義的工作，但不要希望在短期内完成 - HashNode AMA with Brian Terlson
TypeScript 喜歡 Flow
在 2017 年，你大概看到了很多
文章在讨論 TypeScript + Flow 的組合。
Flow是 JavaScript的靜态類型檢查器。 通過 Flow 你可以在圖表中看到 JavaScript 的狀态，這裡面的内容包含了你感興趣和不感興趣的。盡管很多人還沒有聽說過 Flow，但是他們應該會對一些狀态感興趣。如果人們在 2018 年學習了更多的 Flow，那他們就會發現
Minko Gechev所做的有用的事：
TypeScript 和 Flow 消除了你的産品中大約 15% 的 bug！ 還覺得類型系統沒有用麼？ https://t.co/koG7dFCSgF
Angular 喜歡 TypeScript
你可能注意到在 Angular 文檔中所有的代碼例子就是由 TypeScript 寫的。曾經在某個時候，有一種建議，你應該選擇過一遍 JavaScript 或者 TypeScript 的手冊，不過，看起來 Angular 的心已經動搖了。檢視連接配接 Angular 到 JS 風格的圖表，我們會看到實際上有一小部分會被Angular 連接配接到 ES6（TypeScript: 3777, ES6: 3997）。我們靜待它在 2018 對 Angular 的影響。
有關如何為您的下一個應用程式選擇正确的 JavaScript 架構的一些專家建議，請參閱
此白皮書毫無疑問，我們的 JavaScript 将在 2018 年快速發展。作為程式員，我們喜歡編寫和使用那些讓我們的生活更輕松的工具。不幸的是，這有時會導緻更多的混亂和太多的選擇。值得慶幸的是，指令行工具正在幫助我們減輕一些煩瑣的工作，并且 TypeScript 已經滿足了那些對類型錯誤感到厭惡的開發者。
JavaScript 的未來
想要深入了解我們在 JavaScript 的發展方向？ 不妨檢視我們的最新文章“2018 年 JavaScript 的未來及遠方”
原文釋出時間為：2018年01月15日
原文作者：
oschina本文來源開源中國如需轉載請聯系原作者