5种前端代码共享方案:npm包、git submodules、脚手架模板、复制、UMD或模块联邦

背景

我独立开发了《联机桌游合集》,是个网页,可以很方便的跟朋友联机玩斗地主、五子棋、象棋等游戏。这些游戏是不同的前端项目,而这些项目有很多公共依赖,我是如何管理的呢?是如何做方案选型的呢?

今天,我先介绍5种前端代码共享方案,我使用的方案就是从这5种中选择的2种。这五种包括:

  • npm包
  • git submodules
  • 脚手架模板生成
  • 复制
  • UMD或模块联邦

npm包

被共享的代码作为npm包,由引用方通过npm install安装。

特点

  1. 因为给个名字和版本号即可被安装,而且文档可以挂在npm网站(或公司内网镜像npm网站)上,所以适合跨团队、跨组织协作。
  2. 暴露的是打包后的代码,篡改成本较大,通常认为引用方不会修改源码。
  3. 开发者主要靠文档了解API,无需关注源码。
  4. 有版本管理机制,各个引用方可以按需更新。

适用场景

  1. 跨团队、跨组织协作。
  2. 有完善的使用文档。

误区

很多人认为,自己开发都是私有库,是不是不能用npm了?你可能以为npm必须发布到公开的,才能用。

其实不是这样的,npm也可以从git仓库安装依赖。你可以不发布到npm,也可以只把产物(或源码)上传git仓库。

所以个人开发者也能用npm,只是我认为效率不高罢了,不如直接用 git submodules。

git submodules

我在文章《Git Submodules 介绍(通俗易懂,总结了工作完全够用的 submodule 命令)》详细介绍了 Git Submodules,强烈建议阅读。

特点

  1. 因为暴露的是源代码,引用方必须有子模块的读权限,所以适合团队内、组织内协作或个人开发。
  2. 通常允许引用方开发者修改子模块代码,并提交。修改子模块代码的成本较低。
  3. 开发者主要靠阅读源码了解API和机制。
  4. 有版本管理机制,各个引用方可以按需更新。

适用场景

  1. 团队、组织内部协作。
  2. 引用方时常需要修改共享代码。

脚手架模板生成

举个例子,create-react-appvite等都有一些初始化项目的模板。其实大多数前端项目都是以这些模板为起点,逐渐迭代。而且很多公司都有自己的项目脚手架,有自己的独特的模板。这些模板,也属于是代码共享方案。

特点

  1. 暴露的是源代码,开发者需要阅读源代码。
  2. 脚手架可能会预先安装一些依赖,这些依赖是npm包,开发者需要阅读脚手架文档来了解。
  3. 代码生成后,代码全放在引用方的仓库里,开发者可能随时修改文件。因此,脚手架模板更新时,项目更新难度相对较高。因为原始模板文件可能已经被改的面目全非了。

注意,使用脚手架模板需要谨慎。你每发布的一个版本必须是长期可用的、或者更新成本极低的。这并不容易,我之后会发文章详细聊聊,如何做好「脚手架模板生成」。

适用场景

  1. 框架脚手架(能够保证所有版本的模板都长期可用)。
  2. 有一些由模板方维护的文件不允许引用方修改(保证更新成本低,可以通过自动化方式更新模板)。

复制

就是把你需要的函数复制到本仓库来。有点类似于「脚手架模板生成」,但又不太一样。

特点

  1. 暴露的是源代码,开发者需要阅读源代码。
  2. 通常复制的代码不会太长,只是一些简单的函数。
  3. 没有版本管理机制,当复制的源头更新后,你可能感知不到源头的更新,也可能你对源码做了修改,因此始终处于旧的版本。

适用场景

  1. 某个npm包没有做按需加载,但你只需要引用一小部分功能。
  2. 引用的代码,已经非常稳定,不必更新,或者没有跟源头保持同步的诉求。

UMD或模块联邦

例如通过script脚本引入,或者通过Webpack5的模块联邦引入。(我把他们放一起,是因为他们思想上是一致的,只是实现方式不同)

特点

  1. 暴露的是打包产物,所以开发者需要阅读文档了解API。
  2. 开发者篡改成本较高,通常认为不会去修改它。
  3. 有版本管理机制,可以通过url指定具体版本号,做到按需更新。也可以使用某个latest的URL,始终保证获取到最新的版本。
  4. 基于浏览器缓存机制,可以降低公共资源的重复加载。

适用场景

  1. 需要自动保持最新版本,且100%相信维护团队。可以使用latest url。(这样每次更新时无需主动发布)
  2. 减少公共资源的重复加载,提高用户体验。

我的选择

  1. 我是个人开发者,所以我放弃了npm包,选用了git submodule。
  2. 我确实有一些不同的项目,需要统一的初始化模板,所以选用了脚手架模板生成。而且我有明确的迭代更新脚手架模板的方案。
  3. 我不需要复制。
  4. 虽然我有一些公共依赖,但是用户加载时间已经很短了,我的资源体积并不大,加载时间不是我的痛点,所以我没有选用UMD、模块联邦。

写在最后

我是HullQin,公众号线下聚会游戏的作者(欢迎关注我,交个朋友)。转发本文前需获得作者HullQin授权。我独立开发了《联机桌游合集》,是个网页,可以很方便的跟朋友联机玩斗地主、五子棋、象棋等游戏,不收费无广告。还开发了《Dice Crush》参加Game Jam 2022。喜欢可以关注我噢~我有空了会分享做游戏的相关技术,会在这个专栏里分享:《教你做小游戏》

版权声明:
作者:HullQin
链接:https://jkboy.com/archives/9708.html
来源:随风的博客
文章版权归作者所有,未经允许请勿转载。

THE END
分享
二维码
海报
5种前端代码共享方案:npm包、git submodules、脚手架模板、复制、UMD或模块联邦
我独立开发了《联机桌游合集》,是个网页,可以很方便的跟朋友联机玩斗地主、五子棋、象棋等游戏。这些游戏是不同的前端项目,而这些项目有很多公共依赖,我是如何管理的呢...
<<上一篇
下一篇>>