了解可执行的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