有必要說說我為什么要開始寫這個，正文從下面的第一條開始
我最近忙於公司的項目，一直沒有抽出時間來寫文章。本來想每個月寫一片文章，保質保量，無奈上個月沒有堅持。
這段時間有點忙，主要是由於公司業務調整，我從原來的廣告項目中調整到新業務線的前台頁面開發了，和以前一樣，還是帶着3、4個兄弟姐妹。不同的是以前的項目周期普遍偏長，可以讓每個同學有時間從頭到尾的把項目吃透，而現在做C端的前台頁面往往開發時間非常的短，比如我們就要在1、2個月完成業務線所有前台頁面的開發、聯調、測試、部署，以及下一步的迭代。由於是從零開始，不存在基於一個“現成的”去做“另一個”。這就要所有的東西一起開發，但是這種聯調成本就會不小。但是新的幾個前台項目又不會一起確定需求，只會一個一個的需求評審、設計出圖、交互、確認再交由前端。server端還好，可以在一開始確認需求后就開工，前端卻要等UI、UE的定稿。由於人手不夠，我已經不能像以前那樣讓每個同學負責一個項目了，一方面，每個項目安排一個同學的話我們人不夠，另一方面每個項目不是一起定稿，晚出設計的項目對應的同學就會一直閑置。而最終專人負責也是在聯調這個關鍵環節讓盡量少的人同時開發，增加穩定性。
最終我們選擇前期“協同開發”后期“專人負責”的方式，打個比方這就像是打籃球防守，“人盯人”不行就得“聯防”。當一個項目確認，設計定稿，我們大家一起上，分別開發這個項目的不同模塊。對於前端來說，前台項目切頁面是一個比較大的工作量，比較適合大家一起開發，而后期聯調又不太時候太多的人一起開發。我們打算這段時間每當有一個項目定稿后，我們大家一起把切頁面和基本交互的工作開發到80%（除聯調的都差不多了），就正好可以趕上繼續下一個項目的定稿，我們再一起切頁面。這樣等這幾個新項目的切頁面完成后，server端同學也達到了差不多可以聯調的程度了。我們再把同學分散到各自項目中去和server端同學聯調。
這次我不打算寫本地mock，原因是對於新業務線的新項目，server和產品需求的不確定性太強，每一天都會收到需求調整的群郵件，一旦我們今天約定了接口格式，我按照現有結構開發了，明天就有可能改，我第二天的工作是繼續我未完成的功能還是根據新調整的接口從新改一遍。這種成本對於一個要趕在年前上線的項目來說，會造成嚴重的delay。最終我打算等接口相對穩定了再聯調。當然二期迭代的時候服務端框架基本穩定，接口格式也穩定了，我們再選擇mock假數據的方式，就比較有利於前后端開發的解耦。
以上是我簡單介紹的業務場景，下面是我要做的事情。解決問題的核心點在於如何讓前期的“協同開發”能夠讓所有同學一起上各自模塊互不干擾，后期專人聯調部署方便快捷。我們需要搭一套前端的工程，說的牛B一點就是寫一套前端架構。但是剛剛我說過我們要這段時間做好幾個項目，不能說每個項目都拷貝一套項目吧，而且一旦在開發的過程中發現我們有考慮不足需要改的地方，就要每個項目改一遍，但是這時第二個項目已經開發過半，也許項目結構也都被實際的開發人員修改。
我最終考慮的方案是“開發工具”＋“業務代碼”的方式。“工具”負責模塊的自動合並打包部署等操作，“業務代碼”負責項目中大家一起開發的模塊、切頁面、和最終的聯調。不同的項目只是業務不同，項目結構都是一致的，一旦項目結構調整，我就更新工具即可。對於新產生的項目，工具也應該提供腳手架，以方便新需求定稿后馬上開始開發。如果使用過vue－cli的同學應該知道那就是一個基於vue的腳手架，可以讓一個開發者在簡單了解vue的文檔后，快速開始業務開發。可以更關注業務。但是我們是C端的前台頁面，考慮到兼容性和服務端結構以及運維部署方式。我們要寫一套適合自身業務特點的“開發工具”。
不過我們可以借鑒這種思路開發一套可以模塊開發、合並、打包、部署的前端工具，發布在npm平台上。大家只要上平台上去install就可以了，更新也可以更方便。
介紹完為什么要有這套工具，下面就是開發這套工具。本文只會講到npm的發布，具體的工具開發會放到后面的文章。我在整理了一下我自己在摸索中發現的一些問題，詳細描述一下。
我們都知道，在npm平台上發布的npm包可以供大家在平台上下載安裝，最方便的地方是可以在項目中通過命令更新，也就是說我在組內使用npm平台管理我的開發工具，就可以在我優化工具的時候，讓其他同學update一下就好了，來實現技術框架和業務代碼的解藕。
npm包說的簡單一點就是就是一個滿足npm規范的文件夾，里面要有一些必要的文件。只要滿足了規范，就可以讓別人使用你的npm包了。那么npm包里面都要有什么呢？下面我一步一步的介紹一下（作為配置介紹，我可能寫的有點兒細，會顯得啰嗦）：
1、首先我要有一個npm賬號
將來我們文件寫好了改發布了，基本的文件都加進去了，我們要發布就要有個平台賬號才行。首先在npm官網注冊https://www.npmjs.com/ ，這個是我們的npm賬號（建議小寫），有兩個地方會用到：1、登陸npm網站管理名下的npm包，比如添加刪除（比如將來哪一個很牛逼的包需要在npm上發布，但是這名字一致被你占用着，經過討論，你為了全人類讓出來）2、在本機的npm配置中加入用戶，發布的時候用。我相信如果你用過git，這一切都不是事兒。
2、起一個好名字？
舉個例子，coodev 是我打算做的一個用來協作開發的工具。我打算在npm平台上發布，在github上維護。
我要建一個叫coodev的包（要現在npm平台搜一下，是否有人已經占用了這個名字了）。我一開始起名字的時候叫codev，發布了好幾回log都顯示失敗了，說是我沒有權限更新codev。我查了半天，擔心是自己賬號有問題。最終發現改個名就好了。所以建議大家先在平台上搜一下，是不是有名字沖突的，想我這么干就有點兒二了。
3、創建項目coodev
這一步不一定要按照我的方法來做，因為我打算在github上維護，在npm上發布，所以我是先在github上創建工程。其實創建npm的過程是差不多的，github的好處是會給我們創建好多默認的文件，比如licenses、生成package.json時的git 相關信息等。不過npm本身並不依賴git。
我git clone自己的coodev后就直接進入自己的倉庫，此時應該只有.gitignore 、LECENSE、README.md文件，這些都嗨不是npm發布所必要的（不打算用git管理的同學，從這后面開始就行了）。我們要想讓別人用我們的npm包，就要遵循npm的規范，這個規范就是package.json。用你的npm包就得先看說明書，package.json就是說明書。過去我對package.json的理解就是標明依賴和npm script腳本，對其他的字段還沒怎么看過。下面開始package.json的創建
進去之后直接npm init創建一個package.json 因為這是一個npm包被外界識別的配置文件，我們先按照向導生成package.json文件，我們會發現如果先使用管理，好多的字段都讀取到了git信息。
4、體現一下存在感（寫個能跑通的小例子）
有幾個比較重要的字段：name,version,main,bin。name是表示包發布的名字；version是每次發布的時候要修改版本好才能生效（供npm識別），因為每次都要修改，所以建議自動化處理；main是項目的入口（別人以npm或commonJS方式來使用），bin是生成的文件（往往打包成獨立文件，供其他的方式直接引用獨立文件）；其他的我就先不介紹了。
我們要跑一遍體現一下存在感，一方面驗證一下流程作為技術調查的一部分，另一方面是趕緊把名給占上。既然要發布，就得聽個響兒。我們把“coodev”在命令行打印出來。
我們在這個文件夾下放一個index.js文件，里面隨意的寫一句console.log("coodev 運行的妥妥的")用來檢測我們的包是否能執行。
當然只是加這一句是不能在mac上全局安裝是使用的，我就遇到這個坑了，我一開始是用window寫的，log也能打印出來，我用mac寫的時候就出問題了：會自動給文件的代碼中加上字符串，並沒有把我的代碼當作語句來識別，而是無法直接運行這個字符串，我后來看了一下webpack的寫法才知道，我們要在文件第一行加一句
#!/usr/bin/env node
接下來就比較重要了，我們要將這個index.js（也可以在別的文件夾，叫別的名）設置為npm包的入口，要不然別人無法通過package.json知道哪一個是入口文件，我們需要分別為了舉例子，我就把main和bin都指向剛剛的index.js文件（我偷懶了），package.json文件如下。
1 { 2 "name": "coodev", 3 "version": "0.0.9", 4 "description": "前端寫作開發流程的腳手架", 5 "main": "index.js", 6 "bin": "index.js", 7 "scripts": { 8 "test": "echo \"Error: no test specified\" && exit 1" 9 }, 10 "repository": { 11 "type": "git", 12 "url": "git+https://github.com/grARM/coodev.git" 13 }, 14 "engines": { 15 "node": ">=0.6" 16 }, 17 "author": "grarm", 18 "licenses": [ 19 { 20 "type": "MIT", 21 "url": "http://www.opensource.org/licenses/mit-license.php" 22 } 23 ], 24 "bugs": { 25 "url": "https://github.com/grARM/coodev/issues" 26 }, 27 "homepage": "https://github.com/grARM/coodev#readme" 28 }
5、發布到平台（npm publish）
按理來說我們應該一早配好npm的賬戶設置，不過我打算把配置和發布放在一起看。首先請准備好剛剛注冊的npm賬號，確保賬號是對的，能登錄。
我們打開你平時用的終端控制台（能用npm命令的地方），我就用最常用git bash，輸入命令npm adduser。
1 $ npm adduser 2 Username: your name 3 Password: your password 4 Email: yourmail[@gmail](/user/gmail).com
按照你注冊的賬號配置好，這時候看一下package.json中author盡量與npm賬戶一致。我們就算基本配好了（只要配一次就行了）。
我們每次寫好npm包的代碼后就可以准備發布了，注意更新package.json中的version，不然npm平台不能識別這是一個更新的包。輸入如下命令：
$ npm publish
如果成功就會出現顯示進度條，並最終顯示如下log：
如果不成功也會有對用的錯誤提示，基本上是包名字沖突、賬戶有誤，或配置不全等。
我們驗證一下是否成功，我們可以登錄npm平台自己賬戶名下，看是不是更新了版本號，如下圖：
如果更新了，我們就試一下。激動人心的時刻到來了，我們找一個別的文件夾，全局安裝我們的coodev或更新， $ npm install －g coodev （mac記得sudo），如下圖：
安裝成功后運行一下： $ coodev ,會顯示下面的內容：
我還要加個參數，畢竟別的包在運行的時候都可以加參數，我也得能讀得到啊。更新index.js如下：
1 #!/usr/bin/env node 2 3 /* 4 MIT License http://www.opensource.org/licenses/mit-license.php 5 Author @grarm 6 */ 7 var path = require('path'); 8 9 console.log("coodev");//注意這回沒寫妥妥的 10 11 var arguments = process.argv.splice(2); 12 13 console.log("arguments:", arguments);
同樣的更新version到 "version": "0.0.10" ，再 $ npm publish 我們再全局更新運行一下就能看到參數了，如下圖：
我想添加一些依賴，我就可以引用好多三方的庫了，以webpack為例我需要引用webpack就直接在命令行輸入 $ npm install webpack@1.12.15 --save 就把依賴添加進去了，這是看我們的package.json就會發現多了一個字段：
1 "dependencies": { 2 "webpack": "^1.12.15" 3 }
發布，再更新就會發現webpack會自動安裝在coodev的目錄下。
那么我的例子就算是跑通了，也算萬里長征的第一步。
總結：
以上是我在開發一個前端工具的第一部分：npm發布的介紹，我后續會繼續分享我在開發前端工具的過程中遇到的問題和解決方案，整理成專題。還希望大家看了以后能指點指點，我也好少走點兒彎路。分享我近期聽到的一段話：走出森林的兩種辦法，一種是拿着地圖，按圖走。方便直接，但是隨着滄海桑田，過去的方案不一定適應今天的問題，一旦地圖不符就有可能迷路；另一種方法是沿着河流走，壞處是河流蜿蜒我們會走一些彎路也許很慢，好處是基於這個真理，一定能走出去，還能在路上結識更多認同這一真理的同伴，相互鼓勵。