我们正在Angular的一个大型应用程序中工作,其中包含许多功能模块,每个功能模块都具有许多组件,服务和路由。
我们想知道将这些功能模块封装在库中是否是一个好主意,以便我们可以将它们作为npm依赖项导入到主项目中,并使它们受到控制。
这个想法是,新开发人员只能在功能模块中工作,使用版本来保持正确并避免主项目中的问题。这类似于在Java项目中使用Maven。
主要说明:这些功能模块不能在其他应用中重用,它们已与此应用耦合。仅在这种情况下,这些库才对版本控制和组织有用。
我们已经阅读了很多有关Angular模块的信息,但是我们希望对此有所了解并提供实际建议。我们非常感谢您的反馈。
非常感谢!
丹妮
答案 0 :(得分:1)
这可能不是一个好主意。语义版本控制很好,是 semantic ,使用库作为开发模式可能会污染您的库版本,并在将来引起其他版本控制和规范问题。
我认为有一点需要考虑:
如果没有,您可能会弄乱版本。
如果库不是独立的:例如,如果业务逻辑同时影响lib-a@1.1.0和lib-b@1.3.0,那么记录CHANGELOG将非常繁琐。如果仅在几个版本之后才存在并发现错误,或者需要强制还原,那么将每个库还原和/或挑选到确切的所需版本将非常容易出错。
这就是为什么依赖另一个库(@typescript-eslint/parser
和@typescript-eslint/eslint-plugin
,rxjs
和rxjs-compat
)的库严格要求您为每个库使用完全相同的版本号-例如,您将必须在同一项目中安装rxjs@6.3.3
和rxjs-compat@6.3.3
。您不能安全地同时使用rxjs@6.2.3
和rxjs-compat@6.3.3
。还建议您安装相同的核心Angular框架库版本号。
但是,只有在每个库(大部分时间)受同一业务逻辑更改影响的情况下,才可能应用一致的版本控制。即使未进行任何相关更改,强制执行一致的版本也是没有意义的。
OR
然后确定,尝试一下。
一致性或独立性。随便挑。
否则,只需使用git flow或基于主干的开发,并进行严格的代码审查以及提交前/提交后的lint检查和测试。只是我的意见。
答案 1 :(得分:1)
如果您认为可行,请尝试将每个功能模块划分为一个独立的微服务。有关微服务的更多信息,请花一点时间阅读本文: https://medium.com/@tomsoderlund/micro-frontends-a-microservice-approach-to-front-end-web-development-f325ebdadc16