NPM是Node.js的包管理工具，隨著Node.js的出現，以及前端開發開始使用gulp、webpack、rollup以及其他各種優秀的編譯打包工具（大多數採用Node.js來實現），大家都開始接觸到一些Node.js，發現了使用NPM來管理一些第三方模組會很方便。
大家搬磚的模式也是從之前的去外掛官網下載XXX.min.js改為了npm install XXX，然後在專案中require或者import。
當然，NPM上邊不僅僅存在一些用來打包、引用的第三方模組，還有很多優秀的工具（包括部分打包工具），他們與上邊提到的模組的區別在於，使用npm install XXX以後，是可以直接執行的。
常見的那些包
可以回想一下，webpack官網中是否有過這樣的字樣：
> npm install webpack -g
> webpack
複製程式碼當然，現在是不推薦使用全域性安裝模式的，具體原因會在下邊提到
以及非全域性的安裝使用步驟：
> npm install webpack
複製程式碼然後編輯你的package.json檔案：
{
"scripts": {
+ "webpack": "webpack"
}
}
複製程式碼再使用npm run就可以呼叫了：
> npm run webpack
複製程式碼以上非全域性的方案是比較推薦的做法
不過還可以順帶一提的是在NPM 5.x更新的一個新的工具，叫做npx，並不打算細說它，但它確實是一個很方便的小工具，在webpack官網中也提到了簡單的使用方法
就像上邊所提到的修改package.json，新增scripts然後再執行的方式，可以很簡單的使用npx webpack來完成相同的效果，不必再去修改額外的檔案。（當然，npx可以做更多的事情，在這裡先認為它是./node_modules/webpack/bin/webpack.js的簡寫就好了）
包括其他常用的一些，像n、create-react-app、vue-cli這些工具，都會直接提供一個命令讓你可以進行操作。
自己造一個簡易的工具
最近面試的時候，有同學的回答讓人哭笑不得：
Q：你們前端開發完成後是怎樣打包的呢？
A：npm run build。
[黑人問號臉.png]。經過再三確認後，該同學表示並沒有研究過具體是什麼，只知道執行完這個命令以後就可以了。
我本以為這僅僅是網上的一個段子，但沒想到真的被我碰到了。也不知道是好事兒還是壞事兒。。
從我個人的角度考慮，還是建議瞭解下你所使用的工具。至少看下scripts裡邊究竟寫的是什麼咯 :)
P.S. npm scripts中不僅僅可以執行NPM模組，普通的shell命令都是支援的
建立工程
首先的第一步，就是你需要有一個資料夾來存放你的NPM包，因為是一個簡單的示例，所以不會真實的進行上傳，會使用npm ln來代替npm publish + npm install。
隨便建立一個資料夾即可，資料夾的名字也並不會產生太大的影響。
然後需要建立一個package.json檔案，可以通過npm init來快速的生成，我個人更喜歡新增-y標識來跳過一些非必填的欄位。
> mkdir test-util
> cd test-util
> npm init -y
複製程式碼建立執行檔案
因為我們這個模組就是用來執行使用的，所以有沒有入口檔案實際上是沒有必要的，我們僅僅需要建立對應的執行檔案即可，需要注意的一點是：與普通的JS檔案區別在於頭部一定要寫上#!/usr/bin/env node
#!/usr/bin/env node
// index.js
console.log('first util')
複製程式碼註冊執行命令
然後就是修改package.json來告訴NPM我們的執行檔案在哪：
{
+ "bin": "./index.js"
}
複製程式碼在只有一個bin，且要註冊的命令與package.json中的name欄位相同時，則可以寫成上邊那種形式，如果要註冊多個可執行命令，那麼就可以寫成一個k/v結構的引數：
{
"bin": {
"command1": "./command1.js",
"command2": "./command2.js"
}
}
複製程式碼呼叫時就是 command1 | command2
模擬執行
接下來我們去找另一個資料夾模擬安裝NPM模組，再執行npm ln就可以了，再執行對應的命令以後你應該會看到上邊的log輸出了：
> cd .. && mkdir fake-repo && cd fake-repo
> npm ln ../test-util
> test-util # global
first util
> npx test-util # local
first util
複製程式碼這樣一個最簡易的可執行包就建立完成了。
npm ln 為 npm link 的簡寫
npm ln <模組路徑> 相當於 cd <模組路徑> && npm ln + npm ln <模組名>
要注意是 模組名，而非資料夾名， 模組名 為package.json中所填寫的name欄位
global 與 local 的區別
因為npm link執行的特性，會將global+local的依賴都進行安裝，所以在使用上不太好體現出兩者的差異，所以我們決定將程式碼直接拷貝到node_modules下：
> npm unlink --no-save test-util # 僅移除 local 的依賴
> cp -R ../test-util ./node_modules/
> npm rebuild
複製程式碼因為繞過了NPM的安裝步驟，一定要記得npm rebuild來讓NPM知道我們的包註冊了bin
這時候我們修改指令碼檔案，在指令碼中新增當前執行目錄的輸出
#!/usr/bin/env node
- console.log('first util')
+ console.log(process.execPath) // 返回JS檔案上層資料夾的完整路徑
複製程式碼這時再次執行兩種命令，就可以看到區別了。
之所以要提到global與local，是因為在開發的過程中可能會不經意的在這裡踩坑。
比如說我們在開發Node專案時，經常會用到nodemon來幫助在開發期間監聽檔案變化並自動重啟。
為了使用方便，很可能會將預定的一個啟動命令放到npm scripts中去，類似這樣的：
{
"script": {
"start": "nodemon ./server.js"
}
}
複製程式碼兩者混用會帶來的問題
這樣的專案在你本地使用是完全沒有問題的，但是如果有其他的同事需要執行你的這個專案，在第一步執行npm start時就會出異常，因為他本地可能並沒有安裝nodemon。
以及這樣的做法很可能會導致一些其它包引用的問題。
比如說，webpack實際上是支援多種語言編寫config配置檔案的，就拿TypeScript舉例吧，最近也一直在用這個。
> webpack --config webpack.config.ts
複製程式碼這樣的命令是完全有效的，webpack 會使用 ts 的直譯器去執行對應的配置檔案
因為webpack不僅僅支援這一種直譯器，有很多種，類似CoffeeScript也是支援的。
所以webpack肯定不能夠將各種語言的直譯器依賴都放到自身的依賴模組中去，而是會根據傳入config的檔案字尾名來動態的判斷應該新增哪些直譯器，這些在webpack的原始碼中很容易找到：
根據webpack動態獲取直譯器的模組interpret來看，.ts型別的檔案會引入這些模組：['ts-node/register', 'typescript-node/register', 'typescript-register', 'typescript-require']，但是在webpack的依賴中你是找不到這些的。
在原始碼中也可以看到，webpack在執行config之前動態的引入了這些直譯器模組。
這裡也可以稍微提一下Node中引入全域性模組的一些事兒，我們都知道，通過npm install安裝的模組，都可以通過require('XXX')來直接引用，如果一些第三方模組需要引入某些其他的模組，那麼這個模組也需要存在於它所處目錄下的node_modules資料夾中才能夠正確的引入。
首先有一點大家應該都知道的，目前版本的NPM，不會再有黑洞那樣深的node_modules了，而是會將依賴平鋪放在node_modules資料夾下。比如說你引入的模組A，A的內部引用了模組B，那麼你也可以直接引用模組B，因為A和B都存在於node_modules下。
還是拿我們剛才做的那個小工具來實驗，我們在fake-repo中新增express的依賴，然後在test-util中新增koa的依賴，並在test-util/index.js中require上述的兩個模組。
你會發現，npx test-util執行正確，而test-util卻直接報錯了，提示express不存在。
我們可以通過NPM的一個命令來解釋這個原因：
> npm root
<current>/node_modules
> npm root -g
<global>/node_modules
複製程式碼這樣輸出兩個路徑應該就能看的比較明白了，koa模組是沒有問題的，因為都是存在於這些路徑下的node_modules，而express則只存在於<current>/node_modules/test-util/node_modules下，全域性呼叫下，require是找不到express的。
# global 下的結構
.
├── /usr/local/lib/node_modules # npm root 的位置
│ ├── koa
│ └── test-util # 執行指令碼所處的位置
└── <workspace> # 本地的專案
├── node_modules
│ └── express
└── .
# local 下的結構
└── <workspace> # 本地的專案
├── node_modules # npm root 的位置
│ ├── koa
│ ├── test-util # 執行指令碼所處的位置
│ └── express
└── .
複製程式碼所以這也從側面說明了為什麼webpack可以直接在自己的檔案中引用並不存在於自己模組下的依賴。
因為webpack認為如果你要使用TypeScript，那麼一定會有對應的依賴，這個模組就是與webpack同級的依賴，也就是說webpack可以放心的進行require，大致這樣的結構：
├── node_modules # npm root 的位置
│ ├── webpack
│ └── typescript
└── . # 在這裡執行指令碼
複製程式碼以及一個相反的栗子?，如果有些依賴在global下安裝了，但是沒有在local下進行安裝，也許會出現這樣的情況，命令直接呼叫的話，完全沒有問題，但是放到npm scripts中，或者使用npx來進行呼叫，則發現提示模組不存在各種balabala的異常。
P.S. 在webpack中，如果模組不存在，並不會給你報錯，而是預設按照JS的方式進行解析，所以可能會遇到提示語法錯誤，這時候不用想了，一定是缺少依賴
也可以說npx是個好東西，儘量使用npx的方式來呼叫，能少踩一些global、local的坑
最終的上線
當然了，真實的開發完一個工具以後，就需要進行提交到NPM上了，這個也是一個很簡單的步驟，npm publish即可，會自動獲取package.json中的name作為包名（重複了會報錯）。
小結
總結了一下關於NPM可執行的包相關的一些東東，希望能夠幫大家簡單的理解這是個什麼，以及global和local下一些可能會遇到的問題，希望能夠讓大家繞過這些坑。
如文中有誤還請指出，NPM工具相關的問題也歡迎來討論。