统计某开源项目的第三方组件列表&vscode使用

前言：

背景

两个开源项目，统计一下组件列表。

那好家伙，我以为很少的内容，一会就统计完了。

一个java：https://github.com/zchuanzhao/jeesns

统计了一下：各层级下的po m.xml文件，打开了引用的jar，war包（在其中发现lib包，包含很多导入的jar文件）

一个前端：https://github.com/renrenio/renren-fast-vue

手工一个一个地统计了package.json文件，行数不多，问题不大。

【nodeJs项目中都会有package.json的存在，这个文件会记录运行该项目所有依赖，并且以平级的形式展示出来】

【在实际中，一个npm包往往会依赖于其他几个甚至几十个包，这些被额外依赖的包是不会记录在项目的package.json中，只会记录在node_modules安装包下的package.json文件中，由于node_modules对于所有的依赖都是并行存放，这样会导致依赖过多不好管理。】

【package-lock.json 内部记录的是每一个依赖的实际安装信息，例如名字，安装的版本号，安装的地址 (npm registry 上的 tar 包地址)等等。也会把依赖的依赖也记录起来，整个文件是一个树形结构，保存依赖嵌套关系。】

{
  \"name\": \"my-lib\",
  \"version\": \"1.0.0\",
  \"lockfileVersion\": 1,
  \"requires\": true,
  \"dependencies\": {
    \"array-union\": {
      \"version\": \"1.0.2\",
      \"resolved\": \"http://registry.npm.taobao.org/array-union/download/array-union-1.0.2.tgz\",
      \"integrity\": \"sha1-mjRBDk9OPaI96jdb5b5w8kd47Dk=\",
      \"dev\": true,
      \"requires\": {
        \"array-uniq\": \"^1.0.1\"
      }
    }
  }
}

【在执行 npm install 的时候，如果发现根目录下只有 package.json 存在（这通常发生在刚创建项目时），就按照它的记录逐层递归安装依赖，并生成一个 package-lock.json 文件。
如果发现根目录下两者皆有（这通常发生在开发同事把项目 checkout 到本地之后），则 npm 会比较两者。如果两者所示含义不同，则以 package.json 为准，并更新 package-lock.json；否则就直接按 package-lock 所示的版本号安装。】

它存在的意义主要有 4 点：

1、在团队开发中，确保每个团队成员安装的依赖版本是一致的。否则因为依赖版本不一致导致的效果差异，一般很难查出来。

2、通常 node_modules 目录都不会提交到代码库，因此要回溯到某一天的状态是不可能的。但现在 node_modules 目录和 package.json 以及 package-lock.json 是一一对应的。所以如果开发者想回退到之前某一天的目录状态，只要把这两个文件回退到那一天的状态，再 npm i 就行了。

3、因为 package-lock.json 已经足以描述 node_modules 的大概信息（尤其是深层嵌套依赖），所以通过这个文件就可以查阅某个依赖包是被谁依赖进来的，而不用去翻 node_modules 目录（事实上现在目录结构打平而非嵌套，翻也翻不出来了）

4、在安装过程中，npm 内部会检查 node_modules 目录中已有的依赖包，并和 package-lock.json 进行比较。如果重复，则跳过安装，能大大优化安装时间。

npm 官网建议：把 package-lock.json 一起提交到代码库中，不要 ignore。但是在执行 npm publish 的时候，它会被忽略而不会发布出去。

题外话//开始😊

package-lock.json的作用：

锁定安装时的包的版本号，并且需要上传到git，以保证其他人在npm install时大家的依赖能保证一致。对整个依赖树进行版本固定。
只能通过 npm install xxx@x.x.x 去更新依赖，然后package-lock.json也能随之更新。
比如：npm install file-saver@1.3.8

package.json中库的版本号详解：

marjor ：这个版本号变化了表示有不可以和上个版本 兼容 的大更改。
minor ：这个版本号变化了表示增加了新的功能，并且可以向后（下）兼容。
patch ：这个版本号变化了表示修复了bug，并且可以向后兼容。
2.5.8对应就是：2是marjor version；5是minor version；8是patch version。

版本号的几种写法（^和~的区别）:

"dependencies": {
    "react": "17.0.1",
    "accepts": "~1.3.7",
    "react-scripts": "^4.0.1"
    }

指定版本：比如2.5.8，安装时只安装指定版本
波浪号~（tilde） +指定版本：比如~2.5.8，表示安装2.5.x的最新版本（不低于2.5.8），但是不安装2.6.x，也就是说安装时不改变主要版本号和次要版本号。
插入号^（caret）+指定版本：比如ˆ2.5.8，表示安装2.x.x的最新版本（不低于2.5.8），但是不安装3.x.x，也就是说安装时不改变主要版本号。
需要注意的是，如果主要版本号为0，则插入号的行为与波浪号相同，这是因为此时处于开发阶段，即使是次要版本号变动，也可能带来程序的不兼容。
latest：安装最新版本
^和~的区别总结起来就是：^能升级“主要版本.次要版本.修补版本”，而~能升级“主要版本.次要版本.修补版本”。（加粗表示能升级的版本号）

波浪符号~曾经是npm安装时候的默认符号，现在默认符号已经变为插入符号^了。

///题外话完😊

看到一个package-lock.json文件，刚开始没注意，还在手工统计，直到我看见统计了这么久，进度条怎么不动，然后发现，有一万多行快两万，此时我已经统计了200多行。

没有时间观念的我，觉得再统计一百次的时间就可以了

于是第三天，我接着统计，觉得时间很多，能做完

直到我发现，该吃晚饭了，我竟然才统计了2000行出头的数量，不得不说人工速度真是太慢了。

我想着，再不赶紧做完就的熬夜了，于是换了统计方式【之前是从上到下统计，换成了挨个统计，某个组件统计完后就删除】，是快了一点，然后我发现半夜十点多了。也才搞了2000多行😓

我想着，这不中啊，还得换方法。

搜了一下json转excel，看到代码感觉我一时半会学不会，放弃了😁

纵欲我想起了一个适合我的方法

VSCode更改任意匹配项

选中后删除 { "version" 把组件名称和版本号弄一行

选中::，command+➡️到行尾，command+Shift+⬅️选择该行内容到行首

把选中的内容剪切到新的文件，然后去除符号什么的就可以了。

把⬆️粘贴到excel，然后使用Ctrl+E分离组件名称和版本号。

又想起来，还有"requires": 里的组件没弄：

选中: ">，和刚才一样，把这行剪切走。
然后依次把>换成0-9【~,^的我没弄】重复步骤😁

在excel中，去除重复项。

其实要不是需要跟别的表格做对比及插入，我早就想到这个方法了哈哈哈哈。

最后也还耗费了2.5小时，把新生成的表格和别的表格 并排 做对比统计。

所以说是2.5小时的活，我搞了一天😭

一些其他操作：

我使用了第五个，有多个光标，那家伙，难操作的很😭

然后还有在war文件里的一些导入的jar包，我使用tree命令来获取了名称

tree -a -f

终于搞完了

devDependencies和dependencies区别

https://blog.csdn.net/u014689760/article/details/94407292

npm install这个命令的参数分–save和–save-dev：

1、为–save -dev 的情况会使得下载的插件放在package.json文件的devDpendencies对象里面

2、为–save的情况会使得下载的插件放在package.json文件的dependencies对象里面

devDependencies用于本地环境开发时候所需要的依赖包。

dependencies用户发布环境，生成上所需要的依赖包

区别：

devDependencies下的依赖包，只是我们在本地或开发坏境下运行代码所依赖的，若发到线上，其实就不需要devDependencies下的所有依赖包；(比如各种loader，babel全家桶及各种webpack的插件等)只用于开发环境，不用于生产环境，因此不需要打包；

dependencies是我们线上(生产坏境)下所要依赖的包，比如vue，我们线上时必须要使用的，所以要放在dependencies下；dependencies依赖的包不仅开发环境能使用，生产环境也能使用

vscode左侧不同颜色标识含义

🐷代码里的左侧颜色标识

红色，未加入版本控制; (刚clone到本地)
绿色，已经加入版本控制暂未提交; (新增部分)
蓝色，加入版本控制，已提交，有改动； (修改部分)
白色，加入版本控制，已提交，无改动；
灰色：版本控制已忽略文件。

取消绿色一：打开项目所在文件夹找到.git文件删除即可
取消绿色二：vscode里面文件名变成了绿色， 并有个绿色的数字1
这些都是文件浏览器的问题。它们使用颜色和指示器来显示哪些文件存在相关问题。
这里的绿色表示文件中有警告，1表示有一个警告。
您可以通过设置：“problems.decorations.enabled”：false来禁用这些选项。

原文链接：https://blog.csdn.net/maxle/article/details/124242738

🐷git文件标识

A: 增加的文件.
C: 文件的一个新拷贝.
D: 删除的一个文件.
M: 文件的内容或者mode被修改了.
R: 文件名被修改了。
T: 文件的类型被修改了。
U: 文件没有被合并(你需要完成合并才能进行提交)
X: 未知状态

修改代码颜色（VSCode 设置注释的颜色为绿色）：
VSCode 安装的插件的主题在"C:\Users\Administrator.vscode\extensions"
找到主题所在的文件夹后用vscode打开里面的theme文件夹里的.json文件