npm包的结构

package.json

  • 版本
    • 每个版本号都形如：1.2.3，有三部分组成，依次叫主版本号、次版本号、修订号；
      1. 当新版本无法兼容基于前一版本的代码时，则提高主版本号；
      2. 当新版本新增了功能和特性，但仍兼容前一版本的代码时，则提高次版本号；
      3. 当新版本仅仅修正了漏洞或者增强了效率，仍然兼容前一版本代码，则提高修订号；
    • ^ 兼容某个大版本。如：^1.1.2 ，表示>=1.1.2 <2.0.0
    • ~ 兼容某个次版本。如：~1.1.2，表示>=1.1.2 <1.2.0
  • 依赖
    1. dependencies 生产依赖
    2. devDependencies 开发依赖
      • 只开发应用，不对外开源的话，包随意放在dependencies或devDependencies是不影响
    3. peerDependencies 同版本的依赖
      • 例如vue和vuex
    4. bundledDependencies 捆绑依赖
      • 依赖中使用到的，但尚未发布
    5. optionalDependencies 可选依赖
      • 非必要不使用
  • files
    • 用于描述npm publish后推送到 npm 服务器的文件列表

package-lock.json

  • 定义每个包的具体版本，以及包之间的层叠关系
  • 需要提交到git吗?
    • 回答: 分情况
      • 内部的应用项目: 可以保证项目中成员、运维部署成员或者是 CI 系统, 在执行 npm install后, 在不同的节点能得到完全一致的依赖安装的内容，减少bug的出现;无需计算依赖版本范围，大部分场景下能大大加速依赖安装时间
      • 给外部环境用的库: 在不使用 package-lock.json的情况下，就可以复用主项目已经安装的包，减少依赖重复和体积

src或lib

  • src/: 包含项目的源代码。在开发过程中，所有的 TypeScript、JavaScript、CSS 等文件会放在这里。
  • lib/:
    • 如果有此文件夹，通常是编译后的代码，生成的文件可以是 CommonJS、ES6 模块等
    • 针对模块化代码的编译输出，保持了一些开发者友好的结构和格式。

dist或build

  • 这个文件夹包含了打包或编译后的代码，通常是在使用构建工具（如 Webpack、Rollup 等）之后生成的。这个文件夹里的代码是实际发布到 npm 上的。
  • 经过优化和打包处理后的生产代码

npm install背后的过程

修改

方法一

方法二

  • 拷贝源文件后进行修改,再引用
  • 缺点:
    • 代码臃肿

方法三

  • fork一份，自己维护
  • 流程:

    还是以elemnt-ui为例,可以在官方的开源代码中fork到自己的仓库中方便维护,然后clone到本地进行相关源代码的修改 使用 npm run dist即可打出对应lib 进行本地软连接, 在本地elemnt-ui项目中使用 npm link 或者 yarn link, 在需要的项目中使用npm linkelemnt-ui,此时就可以进行相关调试 在本地element项目中使用npm login npm publish 进行发包 在需要的项目中引入发布的包,不再使用elemnt官方包,修改packjson中的包版本之后npm unlink elemnt-ui npm install重新安装依赖

  • 缺陷
    • 如果你修改的是个底层包，也就是说并不是你的应用代码中直接引用的，而是你引用的npm包A所依赖的，甚至可能同时被包B依赖的，这时就比较尴尬了，你不可能再去修改A和B的源码，那就太不值当了。
  • 进阶: 使用pnpm的别名(aliases)
    • pnpm add lodash@npm:awesome-lodash: 发布了一个名为awesome-lodash的新包，并使用lodash作为别名来安装它

调试

发布

wip

参考