我們不是有意為之，就是按照出廠設置。

Kristin Armstrong

今天我們就來淺看export尤其是export default。或許你已經注意到，在我們之前看過的例子中，都沒有使用export default（而只有使用export）。這其實是有意義的。如果你愛TS這或許對你來說更為重要。

我們必須擺脫使用export default的習慣。

這出於以下幾點原因（雖然你可能會覺得沒什麼大不了）：

發現不了

IDE（如VSCode）中的IntelliSense很難自動建議export defualt，當你要import他時。因為IntelliSense通常只會自動顯示named exports.

import { "這裡只會建議named exports" } from './ryvn';

CommonJS時很冗贅

在require語句的結尾處放上.default。非常冗贅。

const ryvn = require('./ryvn').default;

Dynamic Import時很冗贅

與CommonJS類似，使用動態導入dynamic import也會需要加.default。

const moduleSpec = "./ryvn.mjs";
import(moduleSpec)
    .then((module) => {
        module.default();
    });

命名問題

當從一個export default導入時，基本上可以給導入的內容起任何你想要的名字。這會導致未來很難在重構，而且會有命名inconsistent和打錯的問題，這種問題會隨著專案的尺度增大而更具嚴重性。順帶一提，named export如果同名，可以在引入時用as關鍵字解決。

再導出問題re-exporting

在創建NPM package時，或者在處理有大量modules的大型package時，使用barrels從一個集中式的地方重新導出modules是很常見的作法。與上述問題類似，這將迫使你重新命名你的export default。

小結

我相信一定許多人認為，這只是coding style的問題，甚至是強烈的個人偏好。但我還是推薦這樣使用，詳細可以看最近的這篇文章：Default Exports in JavaScript Modules Are Terrible。