一、node和npm的基本概念
我们现在搭建一个前端的项目. 首先要配置的环境就是 node 环境.
什么是 node 呢? 也是一个软件包, 它内置了很多可以调用系统软件的 api. 这些 api 就有我们熟悉的 http 模块、fs 模块、tcp 模块. 这些模块让我们前端实现了使用 javaScirpt 直接插手后服务端的开发.
不管是 Windows 还是 mac, 我们都需要配置环境变量, 这个所谓的环境变量呢? 它就是一些路径, 配置好环境变量, 我们才能够通过一些别名, 直接打开路径上面的 exe 文件, 运行这个软件.
而 npm 又是什么呢? 它也是一个软件, 这个软件里面就是使用 JS/TS 来实现调用 node 模块的功能. 所以我们说它是基于 Node.js 的一个命令行工具. 它和http 这些东西是一样. 不同的只是http 模块提供公有网络协议的封装.而npm是封装了如果对Npm的代码仓库的管理.
二、npm install xxxxx
当我们输入npm之后, 它做了啥
whitch npm
ll /opt/homebrew/bin/npm
从这里可以知道,npm就是一个别名, 而这个别名指向的 /opt/hombrew/bin/npm 是一个软链, 这个软链调用的是 /opt/homebrew/lib/node_modules/npm/bin/npm-cli.js 的这个文件.
既然是这样的话. 我们除了能够通过npm 来调用这个文件, 我们也可以直接 通过 node 来调用这个文件
node xxxxx./bin/npm-cli.js
从这文件名可以看出来了, JS写的. 既然是JS写, 那我们就一定能够看得懂. 它写的东西绝不会超出我们的知识范畴.
调试npm源码
npm/cli: the package manager for JavaScript (github.com)
2. 1 npm install流程
2.2 依赖树生成的历史
2.21 npm 2.x
简单的循环遍历
会引起著名的 node_modules黑洞。如下图：
造成这样的原因，是因为对包的管理是依赖于文件系统的，对重复依赖的复用优化设计不足。虽然这个图片放在了npm 2.x这里。但是直到我们现在正在使用的8.x版本，它的包体积和pnpm相比，依旧大很多。不能理解，所以还是老实的使用pnpm为王道！
2.22 npm 3.x
将原有的循环遍历的方式改成了更为扁平的层级结构，将依赖进行平铺。
A 和 B 依赖于 lodash v1.0
C 依赖于 lodash v2.0
带来了新的问题, 如果先加载的C，那么它会将lodash的v2.0版本弄到同级，但是A和B的依赖的v1.0版本依旧重复打包了。这样每次npm install全部的时候，甚至可能会造成 每一次的包体积都不一样。
2.23 npm 5.x
所以为了解决这个版本的问题. 在npm才第一次引入了lock文件. package-lock.json. 18年才引入的. 而yarn 从一出生就有了. 这就是为什么yarn 在这些年大行其道的重要原因.
因为在 package-lock.json 锁文件中已经存放了每个包具体的版本信息和下载链接，这就不需要再去远程仓库进行查询，优先会使用缓存内容从而减少了大量的网络请求，并且对于弱网环境和离线环境更加友好
三、我们为什么需要了解这些历史.
了解这些历史,包括npm依赖书的历史, JS ES3 到 ES8的历史. 并不能够提高我们工作中处理问题的能力. 了解这些历史对于找工作, 甚至对于企业而言,都是没有什么卵用的.
我们毕竟是靠前端这门手艺吃饭的, 即使一开始可能是因为前端入门容易,工资却又比干的高很多. 不过,既然我们依旧入了门, 那花一些闲暇时间来了解一下前端的这些历史是应该的. 只有了解了这些历史. 我们才能够知道,
为什么JQ明明用好, 性能会更强, 但是依旧被淘汰了. 为什么ES6带来的class这个api风风火火的,这两年又被各种函数式给盖过了.甚至网上很多大佬在骂class是岳不群,不阴不阳, 不男不女, 不卵不泡的. 这两年又带来了函数式, 它的崛起到底解决了前端开发的什么问题?
这些都是需要我们提高自身的计算机素养才能够知道的. 而了解它们之前历史就是提高计算机素养很重要的一环.
了解这些历史, 其实就是了解前端,甚至 可以说是计算的知识发展脉络, 这不就是可以帮助你梳理知识体系结构么? 对吧
知识不是无源之水，无根之木。
了解起源、历史进程，才能对现状和未来看的更清楚.
我认为这是架构师应该具有的能力。
“开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 31 天，点击查看活动详情”
