修改npm依赖包

修改npm包的不足

参考:https://mp.weixin.qq.com/s/1oo0aW8kT9Mj88qgvvRx-g

  • 方法1:使用 Fork。
    最常见的方法就是 Fork 源代码,通过在 GitHub 上或其他托管平台上 Fork 第三方包的源代码库。对其源代码进行修改,修改完成后将修改后的包发布到 npm 上。如果你不希望它是公开的,那么你可以搭建一个 npm 的私有包。直接将项目中的包切换我们自己发布的包。
  • 方法2:本地修改与补丁。
    本地修改与补丁方法允许我们对 node_modules 中的包进行必要的修改,同时通过补丁文件的形式保存这些修改。这种方式既可以避免直接修改 node_modules 目录下的代码,也确保了项目的其他成员或在其他环境中部署时能够应用同样的修改。具体步骤如下:
    1. 在本地对包进行修改:直接在项目的 node_modules 目录下找到并修改对应的第三方包文件。虽然这种修改是临时的,但是接下来的步骤会帮助我们保存这些改动。

    2. 创建补丁文件:一旦完成了必要的修改,你可以使用 git diff 或其他差异比较工具来生成一个补丁文件。这个文件记录了修改的内容。如果你的项目使用 Git 进行版本控制,可以先提交所有其他更改,以便 git diff 只显示对第三方包的修改。

      git diff > patches/third-party-package.patch
    3. 应用补丁:为了自动化地在每次安装依赖时应用这个补丁,你可以使用如 patch-package 这样的工具。patch-package 允许在 node_modules 中的包上应用补丁,并且这些补丁可以和你的项目代码一起被版本控制。
      首先,安装 patch-package:
      npm install patch-package postinstall-postinstall --save-dev

      然后,将应用补丁的步骤添加到 package.json 中的 scripts 字段:

      "scripts": {
        "postinstall": "patch-package"
      }

      这样,每次运行 npm install 时,postinstall 脚本都会执行,自动应用保存在 patches/目录下的所有补丁。

  • 方法3:包装第三方包(即对npm进行封装,扩展些自己的功能)
    包装第三方包方法涉及创建一个新的模块(或包),专门用来封装第三方包。通过这种方式,你可以在不直接修改原始包的情况下,添加新的功能、修改现有方法或者调整方法的行为。
    创建一个新的文件(如 third-party-wrapper.js),在这个文件中导入第三方包,并实现需要修改或扩展的功能。
    // third-party-wrapper.js
    import { foo } from "axios";
    
    // 修改或扩展someFunction的行为
    export function enhancedSomeFunction() {
      // 在调用原始函数之前执行一些操作
      console.log("你好");
    
      // 调用原始函数
      let result = foo.apply(this, arguments);
    
      // 在调用原始函数之后执行一些操作
      console.log("小黑子");
    
      // 返回结果
      return result;
    }

    在项目中的其他部分,你可以直接引入并使用这个封装模块,而不是直接使用第三方包。这样,你就可以利用修改后的功能,同时避免了对第三方包的直接修改。

    import { enhancedSomeFunction } from "./third-party-wrapper";
    
    enhancedSomeFunction();

    这种方法的好处是,它提供了一个清晰的隔离层,使得第三方包的任何更新不会直接影响到你对功能的定制。同时,这也使得维护和升级第三方包变得更加容易,因为你只需要在封装层中做出相应的调整。

 

 


 

npm 依赖包多版本管理

参考: https://www.cnblogs.com/wonyun/p/9349691.html

npm 安装同一个包的多个版本【 用npm alias来实现】https://blog.csdn.net/wozhenhaokan/article/details/105504721  或  https://www.cnblogs.com/amiezhang/p/13166240.html

说明:如果一个包从头用到尾,我们一般不会再去引入这个包的另外版本。但是有的项目会碰到 必须 要另外弄个版本的包,或者复制这个版本的包的情况。

比如1: npm里面的一个包A,项目都快开发好了,突然新需求加入进来。需要用到 包 A新版的功能【新版 和 旧版存在兼容性问题】。这时就需要两个版本的包 A 同时存在 node_modules 里。【这种情况出现的情况比较少

比如2:npm的 包 B 里面引入了包 A【B 对 A 进行了封装,项目中用 包 B】。快开发好,突然有个功能用 包 B 实现不了【包B 封装的 功能不上很彻底】,只能用 A。这时项目中 的 包 B 引用了 A,项目文件中 也引用 A。

     导致 打包后运行报错【开发模式没有问题,具体原因不清楚。可能是打包编译时,包 B 对A的 引用 已经 编译了;所以项目中对 A 的引用,就不在编译。而两种 编译 的 使用模式 不一致导致的】。

实践经历:  在开发 "市民卡会务客户端"  electron 桌面软件 时,引用 tim-js-sdk 包就碰到这个问题。

     视频会议 功能  使用 trtc-electron-education 包【对 tim-js-sdk、trtc-electron-sdk 两个包进行了封装。但是这个包没有把 直播功能封装进去】 实现;直播 功能使用  tim-js-sdk、trtc-electron-sdk 实现。

     结果 因为 trtc-electron-education 引用了 tim-js-sdk,外面项目也引用了 tim-js-sdk。开发时没有问题,打包后运行就报错【但是 trtc-electron-sdk 这个包确没有报错,具体里面的 原因应该和 包的设计有关吧】。

     最后 利用 npm alias 实现了,同一个包,以两种 npm 包名共存 在一个 node_modules 中。解决了这个问题。

posted @ 2020-11-14 09:21  吴飞ff  阅读(1544)  评论(0编辑  收藏  举报