答：是通過模板自動生成的
我們從構建指令入手，一步步分析element-ui官方文檔的構建過程
1，構建指令
"deploy:build": "npm run build:file && cross-env NODE_ENV=production webpack --config build/webpack.demo.js && echo element.eleme.io>>examples/element-ui/CNAME",
很顯然這個指令分三部分，
npm run build:file
cross-env NODE_ENV=production webpack --config build/webpack.demo.js
echo element.eleme.io>>examples/element-ui/CNAME （這個沒啥好說的，只是每次構建向CNAME中寫入一句話而已）
首先看 build:file具體內容
"build:file": "node build/bin/iconInit.js & node build/bin/build-entry.js & node build/bin/i18n.js & node build/bin/version.js",
這里分別執行了四個腳本文件,查看他們的內容，顯然是通過node內置的fs指令通過模板文件自動生成另外一些代碼，看看他們生成了什么代碼：
iconInit.js, 這個生成了 /examples/icon.json文件，里面是項目中使用到的圖標，這個icon.json的具體用法傻魚沒有進一步跟蹤，也不是我們關注的重點
build-entry.js, 這個文件生成了elementUI源碼的入口文件，沒錯入口文件是自動生成的！！！ /src/index.js文件 ！！！，仔細想想這樣做的好處，當我們項目越來越龐大的時候，我們希望文件之間盡量減少耦合，比如這里使用模板，我們開發了一個新組建后，不需要人為的去修改入口文件來export我們自己的新組件，這樣是不是減少了發生錯誤的概率。
i18n.js, elementUI的文檔有四個語言版本，看看這個腳本文件生成了那些代碼
它竟然根據一個模板，生成了四個語言版本的vue文件！！！（傻魚一開始以為是在一個vue文件中通過i18n插件進行語言切換而已，現在看來顯然是想錯了。。。）
驚呆了，干嘛不直接使用i18n切換。。。。。。。
version.js，這個生成了一個verson.json文件，里面存了歷史版本號。。。沒啥好說的
接下來我們看
cross-env NODE_ENV=production webpack --config build/webpack.demo.js
環境變量為 production，
查看webpack.demo.js的關鍵代碼
這個文件中入口，出口，啟動端口等都寫得很清楚，我們這時回頭看看examples下的文件，不正是我們熟悉的前端工程嗎。
以前我們把dist文件夾放到Nginx上，現在我們把element-ui 文件夾放到Nginx上
以前入口文件是main文件，現在是entry文件