npm内部机制和核心原理（学习笔记0218）

npm内部机制和核心原理

*Bring the best of open source to you,your team and your company
给你和你的团队、你的公司带来最好的开源库和依赖
—npm的核心目标

在平时开发过程中，解决npm安装类问题的方法主要是
“删除node_modules,重新npm install”
npm的安装机制：优先安装依赖包到当前项目目录 ->同一个依赖包可能在电脑上多次安装

1. 构建依赖树时，应该按照扁平化原则 优先将其放置在 node_modules根目录

2. 同一个团队，应该保证依赖版本的一致

3. 对于一个依赖包的同一版本进行本地化缓存 时当代依赖包管理工具的一个常见设计npm config get cache
   

4. 使用一下命令清除 /Users/cehou/.npm/_Cacache中的文件：npm cache clean --force

5. 打开_cacache文件，npm缓存的3个目录： content-v2（二进制文件） index-v5（content-v2里文件索引） tmp
   这些缓存时如何呗利用的呢？
   1.当npm install执行时，通过pacote把相应的包解压到对应的node_modules下面
   2.pacote依赖npm-registry-fetch来下载包，在给定的路径下根据IETF-RFC 7234生成缓存数据
   3.在每次安装资源时，根据package-lock.json中存储的integrity、version、name信息生成一个唯一的key
   4.如果发现有缓存紫元，就会找到tar包的hash，再次通过pacote把对应的二进制文件解压到相应的项目node_modules下面
   *注意 缓存策略是从npm v5版本开始的，在npm v5版本之前 每个缓存的模块在~/.npm 文件夹中以模块名的形式直接存储
   存储结构是：{cache}/{name}/{version}

npm小技巧

自定义npm init
npm init 命令调用shell脚本输出一个初始化的package.json文件

npm config set init-module~\.npm-init.js 确保npm init所对应的脚本指向正确的文件

假如开发一个组件库，某个组件开发完成之后 如何验证该组件能在我的业务项目中正常运行呢

• 在组件开发中 ，设计examples 目录或者一个playground启动一个开发服务，以验证组件的运行情况（缺点：不能发布一个不安全的包版本 供业务使用）
• 手动复制粘贴组件并打包产出到业务项目的node_modules中进行验证（过于依赖手工执行 非常原始）
• 高效 使用npm link，将模块链接到对应的业务项目中运行
  npm link 的本质就是软链接，主要做了两件事：
  1.为目标npm模块（npm-package 1)创建软链接，将其链接到全局node 模块安装路径/user/local/lib/node_modules/中
  2.为目标npm模块（npm-package1)的可执行bin文件创建软链接 将其链接到全局node命令安装路径 /user/local/bin中
  npm link能够在工程上解决依赖包在任何一个真实项目中进行调试的问题，并且操作起来更加方便快捷

npx的作用

 在传统npm模式下，要使用eslint，要通过npm install安装，然后在项目根目录下执行操作 或者通过项目脚本和package.json调用字段
 但用npx操作起来就简便多了,npx执行模块时会优先安装依赖，但是在安装执行后便删除此依赖，这就避免了全局安装模块带来的问题

npx eslint -init
npx eslint yourfile.js

npm多源镜像和企业级部署私服原理

国内很多使用的nrm是npm的镜像源管理工具

• 部署镜像后，确保高速、稳定的npm服务使发布私有模块更加安全
• 审核机制，保障私服上的npm模块质量和安全

如何部署一个私有的npm镜像

> nexus   verdaccio   cnpm

npm配置作用优先级