多个前端项目中公共组件使用方案(npm包方式)

简介: 多个前端项目中公共组件使用方案(npm包方式)

1、背景

公司有多个前端项目,每个项目独立部署,各个项目里可能会使用相同的组件或者页面。对于这样的组件或者页面如何管理呢?我们可以把公共的组件或者页面抽离,单独存放在一个项目里,然后在其他项目里引入这个公共的项目

2、方案

2.1 创建一个公共组件项目commonpack(名字自己定义),如下图


image.png


image.png


outPages目录里是公共组件pageA和pageB,然后在根目录下创建index.js,向外暴露组件pageA和pageB。index.js文件里面代码如下

import pageA from './outPages/pageA'
import pageB from './outPages/pageB'
export {
  pageA,
  pageB
}

2.2 创建一个标准的前端项目packageone,packagetwo,那么packageone,packagetwo如何来引入公共组件项目commonpack里的组件pageA和pageB呢?有3个方案。

方案一:npm发布引用

公共组件项目commonpack的组件编写完成后,将其发布到npm。开发packageone,packagetwo的人员通过npm install命令将commonpack以node_module的方式引入

npm install commonpack --save

另外,每次改动代码再次发布时,需要修改package.json文件中的版本号,不然发布不成功。

这种方法在开发阶段不便捷,改个公共组件,改完还得发包,发完后其他项目使用还得从新安装。

方案二:npm link

首先进入commonpack包,在控制台输入

npm link

这会创建一个软连接,并保存到目录C:\Users\Administrator\AppData\Roaming\npm\node_modules下面。

然后进入packageone和packagetwo,在控制台输入

npm link commonpack

这就将这个公共的项目通过软连接的方式引入到项目里面来了。下图可以看到在node_modules中common包和其他的包文件夹样式是不一样的,common文件夹只是一个软链接。

image.png

image.png


这时修改commonpack项目下面的任意代码都会实时生效,不用打包,不用更新引入包,也不用重启。

需要注意的是,当项目包依赖更新后,也就是执行了 npm install xxx 之后,需要重新link common项目。而且使用npm link后本地package.json里没有记录,无法直观的查看本地包的引用。

方案三:npm本地file引用(推荐)

分别进入packageone和packagetwo,在控制台输入命令:

npm install ../commonpack/

其中/commonpack/是commonpack的相对路径,这里也可以输入绝对路径。

这样就将commonpack这个工程以node_module的方式引入到packageone和packagetwo项目中了。可以正常使用commonpack在index.js中导出的组件了。

命令执行完后,package.json里会多一条记录


image.png


image.png

同样这时修改common项目下面的任意代码都会实时生效,不用打包,不用更新引入包,也不用重启。而且在package.json中有引入记录。

3、举例

我们在packageone项目里引入公共组件pageA和pageB


image.png


image.png


效果如下


image.png


image.png

github项目地址:https://github.com/Amosyue/npmPackages


相关文章
|
11天前
|
JavaScript 前端开发 Docker
前端全栈之路Deno篇(二):几行代码打包后接近100M?别慌,带你掌握Deno2.0的安装到项目构建全流程、剖析构建物并了解其好处
在使用 Deno 构建项目时,生成的可执行文件体积较大,通常接近 100 MB,而 Node.js 构建的项目体积则要小得多。这是由于 Deno 包含了完整的 V8 引擎和运行时,使其能够在目标设备上独立运行,无需额外安装依赖。尽管体积较大,但 Deno 提供了更好的安全性和部署便利性。通过裁剪功能、使用压缩工具等方法,可以优化可执行文件的体积。
前端全栈之路Deno篇(二):几行代码打包后接近100M?别慌,带你掌握Deno2.0的安装到项目构建全流程、剖析构建物并了解其好处
|
2天前
|
前端开发 数据可视化 搜索推荐
深入剖析极态云优雅的前端框架设计方案(上)
最近在体验极态云,这款低代码软件开发产品,发现其前端框架设计方案很优雅很强大! 在接下来的学习过程中,我将持续输出自己对极态云前端框架设计方案的深入理解,包括具体的使用技巧、优势分析以及可能的应用场景等方面的内容,希望能为大家提供有价值的参考。
|
13天前
|
JavaScript 安全 测试技术
vue封装组件发布到Npm
【10月更文挑战第17天】
|
7天前
|
前端开发 JavaScript 开发者
揭秘前端高手的秘密武器:深度解析递归组件与动态组件的奥妙,让你代码效率翻倍!
【10月更文挑战第23天】在Web开发中,组件化已成为主流。本文深入探讨了递归组件与动态组件的概念、应用及实现方式。递归组件通过在组件内部调用自身,适用于处理层级结构数据,如菜单和树形控件。动态组件则根据数据变化动态切换组件显示,适用于不同业务逻辑下的组件展示。通过示例,展示了这两种组件的实现方法及其在实际开发中的应用价值。
13 1
|
10天前
|
缓存 前端开发 JavaScript
前端serverless探索之组件单独部署时,利用rxjs实现业务状态与vue-react-angular等框架的响应式状态映射
本文深入探讨了如何将RxJS与Vue、React、Angular三大前端框架进行集成,通过抽象出辅助方法`useRx`和`pushPipe`,实现跨框架的状态管理。具体介绍了各框架的响应式机制,展示了如何将RxJS的Observable对象转化为框架的响应式数据,并通过示例代码演示了使用方法。此外,还讨论了全局状态源与WebComponent的部署优化,以及一些实践中的改进点。这些方法不仅简化了异步编程,还提升了代码的可读性和可维护性。
|
12天前
|
缓存 前端开发 JavaScript
前端架构思考:代码复用带来的隐形耦合,可能让大模型造轮子是更好的选择-从 CDN 依赖包被删导致个站打不开到数年前因11 行代码导致上千项目崩溃谈谈npm黑洞 - 统计下你的项目有多少个依赖吧!
最近,我的个人网站因免费CDN上的Vue.js包路径变更导致无法访问,引发了我对前端依赖管理的深刻反思。文章探讨了NPM依赖陷阱、开源库所有权与维护压力、NPM生态问题,并提出减少不必要的依赖、重视模块设计等建议,以提升前端项目的稳定性和可控性。通过“left_pad”事件及个人经历,强调了依赖管理的重要性和让大模型代替人造轮子的潜在收益
|
17天前
|
缓存 JavaScript 前端开发
拿下奇怪的前端报错(三):npm install卡住了一个钟- 从原理搞定安装的全链路问题
本文详细分析了 `npm install` 过程中可能出现的卡顿问题及解决方法,包括网络问题、Node.js 版本不兼容、缓存问题、权限问题、包冲突、过时的 npm 版本、系统资源不足和脚本问题等,并提供了相应的解决策略。同时,还介绍了开启全部日志、使用替代工具和使用 Docker 提供 Node 环境等其他处理方法。
168 0
|
17天前
|
缓存 前端开发 UED
前端 8 种图片加载优化方案梳理
本文首发于微信公众号“前端徐徐”,详细探讨了现代网页设计中图片加载速度优化的重要性及方法。内容涵盖图片格式选择(如JPEG、PNG、WebP等)、图片压缩技术、响应式图片、延迟加载、CDN使用、缓存控制、图像裁剪与缩放、Base64编码等前端图片优化策略,旨在帮助开发者提升网页性能和用户体验。
93 0
|
17天前
|
前端开发 JavaScript 开发工具
从零开始:构建、打包并上传个人前端组件库至私有npm仓库的完整指南
从零开始:构建、打包并上传个人前端组件库至私有npm仓库的完整指南
128 0
|
18天前
|
前端开发 JavaScript 开发工具
前端代码规范和质量是确保项目可维护性、可读性和可扩展性的关键(三)
前端代码规范和质量是确保项目可维护性、可读性和可扩展性的关键(三)
27 0

推荐镜像

更多