了解可执行的NPM包

NPMNode.js的包管理工具,随着Node.js的出现,以及前端开发开始使用gulpwebpackrollup以及其余各类优秀的编译打包工具(大多数采用Node.js来实现),你们都开始接触到一些Node.js,发现了使用NPM来管理一些第三方模块会很方便。
你们搬砖的模式也是从以前的去插件官网下载XXX.min.js改成了npm install XXX,而后在项目中require或者import前端

固然,NPM上边不只仅存在一些用来打包、引用的第三方模块,还有不少优秀的工具(包括部分打包工具),他们与上边提到的模块的区别在于,使用npm install XXX之后,是能够直接运行的。vue

常见的那些包

能够回想一下,webpack官网中是否有过这样的字样:node

```> npm install webpack -g

> webpackreact

<blockquote>固然,如今是不推荐使用全局安装模式的,具体缘由会在下边提到</blockquote>
<p>以及非全局的安装使用步骤:</p>
```&gt; npm install webpack

而后编辑你的package.json文件:webpack

{
  "scripts": {
+    "webpack": "webpack"
  }
}
```

再使用就能够调用了:git

```> npm run webpack ```
以上非全局的方案是比较推荐的作法

不过还能够顺带一提的是在更新的一个新的工具,叫作,_并不打算细说它,但它确实是一个很方便的小工具,在官网中也提到了简单的使用方法_ github

就像上边所提到的修改,添加而后再执行的方式,能够很简单的使用来完成相同的效果,没必要再去修改额外的文件。_(固然,能够作更多的事情,在这里先认为它是的简写就行了)_ web

包括其余经常使用的一些,像、、这些工具,都会直接提供一个命令让你能够进行操做。面试

本身造一个简易的工具

最近面试的时候,有同窗的回答让人啼笑皆非: vue-cli

Q:大家前端开发完成后是怎样打包的呢?
A:。

[黑人问号脸.png]。通过再三确认后,该同窗表示并无研究过具体是什么,只知道执行完这个命令之后就能够了。
我本觉得这仅仅是网上的一个段子,但没想到真的被我碰到了。_也不知道是好事儿仍是坏事儿。。_

从我我的的角度考虑,仍是建议了解下你所使用的工具。_至少看下里边究竟写的是什么咯 :)_
P.S. 中不只仅能够执行模块,普通的命令都是支持的

建立工程

首先的第一步,就是你须要有一个文件夹来存放你的包,由于是一个简单的示例,因此不会真实的进行上传,会使用来代替 + 。

随便建立一个文件夹便可,文件夹的名字也并不会产生太大的影响。
而后须要建立一个文件,能够经过来快速的生成,我我的更喜欢添加标识来跳过一些非必填的字段。

```> mkdir test-util > cd test-util > npm init -y ```

建立执行文件

由于咱们这个模块就是用来执行使用的,因此有没有入口文件其实是没有必要的,咱们仅仅须要建立对应的执行文件便可,须要注意的一点是:__与普通的文件区别在于头部必定要写上__


注册执行命令

而后就是修改来告诉咱们的执行文件在哪:

{
+  "bin": "./index.js"
}
```

在只有一个,且要注册的命令与中的字段相同时,则能够写成上边那种形式,若是要注册多个可执行命令,那么就能够写成一个结构的参数:



  
  
  
  
调用时就是 command1 | command2

模拟执行

接下来咱们去找另外一个文件夹模拟安装模块,再执行就能够了,再执行对应的命令之后你应该会看到上边的输出了:

```> cd .. && mkdir fake-repo && cd fake-repo > npm ln ../test-util

> test-util # global
first util
> npx test-util # local
first util


由于绕过了的安装步骤,必定要记得来让知道咱们的包注册了

这时候咱们修改脚本文件,在脚本中添加当前执行目录的输出

#!/usr/bin/env node

   
   
   
   
  • console.log('first util')
  • console.log(process.execPath) // 返回JS文件上层文件夹的完整路径

{
"script": {
"start": "nodemon ./server.js"
}
}



   
   
   
   
这样的命令是彻底有效的,webpack 会使用 ts 的解释器去执行对应的配置文件

由于不只仅支持这一种解释器,有不少种,相似也是支持的。
因此确定不可以将各类语言的解释器依赖都放到自身的依赖模块中去,而是会根据传入的文件后缀名来动态的判断应该添加哪些解释器,这些在的源码中很容易找到:

  1. 获取配置文件后缀
  2. 获取对应的解释器并引入模块注册

根据动态获取解释器的模块interpret来看,类型的文件会引入这些模块:,可是在的依赖中你是找不到这些的。

在源码中也能够看到,在执行以前动态的引入了这些解释器模块。

这里也能够稍微提一下中引入全局模块的一些事儿,咱们都知道,经过安装的模块,均可以经过来直接引用,若是一些第三方模块须要引入某些其余的模块,那么这个模块也须要存在于它所处目录下的文件夹中才可以正确的引入。

首先有一点你们应该都知道的,目前版本的,不会再有黑洞那样深的了,而是会将依赖平铺放在文件夹下。好比说你引入的模块,的内部引用了模块,那么你也能够直接引用模块,由于和都存在于下。

仍是拿咱们刚才作的那个小工具来实验,咱们在中添加的依赖,而后在中添加的依赖,并在中上述的两个模块。

你会发现,运行正确,而却直接报错了,提示不存在。

咱们能够经过的一个命令来解释这个缘由:

```> npm root <current>/node_modules > npm root -g <global>/node_modules ```

这样输出两个路径应该就能看的比较明白了,模块是没有问题的,由于都是存在于这些路径下的,而则只存在于下,全局调用下,是找不到的。

```# 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
└── .


以及一个相反的栗子🌰,若是有些依赖在下安装了,可是没有在下进行安装,也许会出现这样的状况,命令直接调用的话,彻底没有问题,可是放到中,或者使用来进行调用,则发现提示模块不存在各类balabala的异常。
P.S. 在中,若是模块不存在,并不会给你报错,而是默认按照的方式进行解析,因此可能会遇到提示语法错误,这时候不用想了,必定是缺乏依赖

也能够说是个好东西,尽可能使用的方式来调用,能少踩一些、的坑

最终的上线

固然了,真实的开发完一个工具之后,就须要进行提交到上了,这个也是一个很简单的步骤,便可,会自动获取中的做为包名(重复了会报错)。

小结

总结了一下关于可执行的包相关的一些东东,但愿可以帮你们简单的理解这是个什么,以及和下一些可能会遇到的问题,但愿可以让你们绕过这些坑。
如文中有误还请指出,工具相关的问题也欢迎来讨论。

参考资料

来源:http://www.javashuo.com/article/p-tnlwxtcu-y.html

npm runNPM 5.xnpxwebpackpackage.jsonscriptsnpx webpacknpx./node_modules/webpack/bin/webpack.jsncreate-react-appvue-clinpm run buildscriptsnpm scriptsNPMshellNPMnpm lnnpm publishnpm installpackage.jsonnpm init-yJS#!/usr/bin/env node#!/usr/bin/env node // index.js console.log('first util')package.jsonNPMbinpackage.jsonnamek/v{ "bin": { "command1": "./command1.js", "command2": "./command2.js" } }NPMnpm lnlog<p>这样一个最简易的可执行包就建立完成了。</p> <blockquote>npm ln 为 npm link 的简写 <br>npm ln &lt;模块路径&gt; 至关于 cd &lt;模块路径&gt; &amp;&amp; npm ln + npm ln &lt;模块名&gt; <br>要注意是 <strong>模块名__,而非文件夹名, __模块名</strong> 为<code>package.json</code>中所填写的<code>name</code>字段</blockquote> <h3>global 与 local 的区别</h3> <p>由于<code>npm link</code>执行的<a href="https://docs.npmjs.com/cli/link#description" rel="nofollow noreferrer">特性</a>,会将<code>global</code>+<code>local</code>的依赖都进行安装,因此在使用上不太好体现出二者的差别,因此咱们决定将代码直接拷贝到<code>node_modules</code>下:</p> ```&gt; npm unlink --no-save test-util # 仅移除 local 的依赖 &gt; cp -R ../test-util ./node_modules/ &gt; npm rebuildNPMnpm rebuildNPMbin<p>这时再次执行两种命令,就能够看到区别了。 </p> <p>之因此要提到<code>global</code>与<code>local</code>,是由于在开发的过程当中可能会不经意的在这里踩坑。 <br>好比说咱们在开发<code>Node</code>项目时,常常会用到<code>nodemon</code>来帮助在开发期间监听文件变化并自动重启。 <br>为了使用方便,极可能会将预约的一个启动命令放到<code>npm scripts</code>中去,相似这样的:</p><h4>二者混用会带来的问题</h4> <p>这样的项目在你本地使用是彻底没有问题的,可是若是有其余的同事须要运行你的这个项目,在第一步执行<code>npm start</code>时就会出异常,由于他本地可能并无安装<code>nodemon</code>。 </p> <p>以及这样的作法极可能会致使一些其它包引用的问题。 <br>好比说,<code>webpack</code>其实是支持多种语言编写<code>config</code>配置文件的,就拿<code>TypeScript</code>举例吧,最近也一直在用这个。</p> ```&gt; webpack --config webpack.config.tswebpackCoffeeScriptwebpackconfigwebpackwebpack.ts['ts-node/register', 'typescript-node/register', 'typescript-register', 'typescript-require']webpackwebpackconfigNodenpm installrequire('XXX')node_modulesNPMnode_modulesnode_modulesAABBABnode_modulesfake-repoexpresstest-utilkoatest-util/index.jsrequirenpx test-utiltest-utilexpressNPMkoanode_modulesexpress<current>/node_modules/test-util/node_modulesrequireexpress<p>因此这也从侧面说明了为何<code>webpack</code>能够直接在本身的文件中引用并不存在于本身模块下的依赖。 </p> <p>由于<code>webpack</code>认为若是你要使用<code>TypeScript</code>,那么必定会有对应的依赖,这个模块就是与<code>webpack</code>同级的依赖,也就是说<code>webpack</code>能够放心的进行<code>require</code>,大体这样的结构:</p> ```├── node_modules # npm root 的位置 │   ├── webpack │   └── typescript └── . # 在这里执行脚本globallocalnpm scriptsnpxwebpackJSnpxnpxgloballocalNPMnpm publishpackage.jsonnameNPMgloballocalNPM
相关文章
相关标签/搜索