瞭解可執行的NPM包

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的源碼中很容易找到：

1. 獲取配置文件後綴
2. 獲取對應的解釋器並引入模塊註冊

根據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工具相關的問題也歡迎來討論。

參考資料

• npm-bin
• webpack-cli