Angular-cli: [RFC]库支持和样板注释线程

创建于 2017-05-30  ·  163评论  ·  资料来源: angular/angular-cli

作为https://github.com/angular/angular-cli/issues/1692#issuecomment -304970595的跟进。

在这里继续转换。

RFC / discussion / question faq

最有用的评论

请原谅我的法语,可是WTF? Angular跳了鲨鱼吗?

组件框架的首要任务之一是促进组件的可重用性。 我不知道什么是Angular Devkit,也不了解多应用程序支持的含义。 我只想包装一个很小的组合框,然后与团队和/或整个世界共享。

在这一领域缺乏标准化和缺乏指导确实在损害生态系统。

我意识到基本的复杂性超出了任何仅使用NG的休闲应用程序开发人员的理解,但是坦率地说,将您的双手放在心上,问自己这个问题:

“我们是否陷入了一个复杂的黑洞?”

NG2的希望是消除NG1的复杂性和陌生性。 现在是进行真诚自省的时候了。

同时,对于我们来说,他们必须向我们的经理解释什么是JIT或AOT,以及为什么构建完美(尽管它们是非常好的Typescript)会随机中断,以及为什么提取这么多已经可以在另一个项目中使用的通用功能的过程花费如此长的时间, ,我们可能会被迫跳船。

所有163条评论

@hansl

感谢您的正式答复。
希望很快能收到团队的更新:)

来自我的想法(我维护ngrx和Angular devrel)

从长远来看,这将在devkit中实现,但这是一个相当重大的体系结构更改。 在此期间,让我们从“种子”风格的仓库开始,人们可以分叉并开始使用。

MVP应该基本上:

  • 使用npm脚本运行任务,并设置构建/测试/发布:来自ngrx / store的示例: https :
  • 使用ngc +汇总生成FESM +元数据+ d.ts(尽管这实际上仅适用于单一功能的事物-对于材料类型的巨型存储库,这不是理想的过程。
  • 具有最小的测试设置+集成规范以验证功能+ AoT友好热线

除此之外,所有其他内容都将迅速进入本周的“骑行除草最佳实践” /“ fav代码覆盖”工具领域,因此,让我们从最低限度开始,然后从那里开始。

首先感谢@hansl的更新,非常感谢。

我想了解ng cli的未来,这与Angular Development Kit和生成自定义模板的工具相适应。

我们公司投入了大量的时间和精力来使用Angular 4.x并使用ng cli,尽管许多重构者都认为库的生命周期很长。 我们目前正在使用类似于@robwormald描述的自定义构建过程来构建和测试我们的组件库,我们希望一旦此功能登陆cli就可以将其删除。

我担心的是,一旦这些新工具登陆,我们将不得不再次更改非图书馆应用程序的构建过程,还是仅仅针对图书馆项目?

在Google,我们为此使用“二进制”和“库”这两个术语:

  • 二进制文件是可移植到浏览器的工件,它是“自我执行”的
  • 库被设计为供二进制文件(或其他库)使用

当前的Angular CLI从一开始就被构建为用于管理二进制文件的工具。 在早期,当我们使用ember-cli +西兰花时,输出库本来会更简单,因为它自以为是且更灵活。 Angular社区要求(正确地,IMO)要求我们切换到Webpack。 Webpack旨在构建二进制文件,因此我们有点卡住了。

@mattem不能让您访问Webpack内部的全部要点是,它的目标是在我们开发基础工具时允许无缝过渡。 长期而言,我们的目标是大大简化整个过程,但这需要时间。 该线程的目的是提供一个临时解决方案。

@mattem长期而言,我们正在努力消除将元数据等需求运送到npm的需求,从而有利于运送预编译的代码。 我们已经有了此设置,以使我们能够灵活使用编译器API(这是我们可以在v2-v4之间进行更改的所有功能)-对API满意后,我们会将其标记为public,这将打开带来了许多非常酷的新可能性。 (目前)在路线图上大约有一年的时间,但是为此进行的准备工作正在进行中。

@mattem Rob没有回答这个问题,所以我要a一下:

我想了解ng cli的未来,这与Angular Development Kit和生成自定义模板的工具相适应。

DevKit将是您可以编写脚本或开发的一组库和工具。 其中的一部分将是构建,测试和生成文件。 这听起来确实是通用的,因为它是。 API级别将强制执行许多约定,因此工具(例如IDE,脚本或CI)将以类似的方式工作。

将来的CLI(版本2?3?)将仅是在后台使用DevKit并从用户中抽象出来的工具。 如果您今天使用CLI,那么将来您应该对CLI非常熟悉。 真正的区别是,下面的每个零件都将能够被其他工具独立使用。 因此,您可以看到一个VSCode扩展,它知道如何构建您的应用程序/库,它使用与CLI相同的代码路径。

请原谅我的法语,可是WTF? Angular跳了鲨鱼吗?

组件框架的首要任务之一是促进组件的可重用性。 我不知道什么是Angular Devkit,也不了解多应用程序支持的含义。 我只想包装一个很小的组合框,然后与团队和/或整个世界共享。

在这一领域缺乏标准化和缺乏指导确实在损害生态系统。

我意识到基本的复杂性超出了任何仅使用NG的休闲应用程序开发人员的理解,但是坦率地说,将您的双手放在心上,问自己这个问题:

“我们是否陷入了一个复杂的黑洞?”

NG2的希望是消除NG1的复杂性和陌生性。 现在是进行真诚自省的时候了。

同时,对于我们来说,他们必须向我们的经理解释什么是JIT或AOT,以及为什么构建完美(尽管它们是非常好的Typescript)会随机中断,以及为什么提取这么多已经可以在另一个项目中使用的通用功能的过程花费如此长的时间, ,我们可能会被迫跳船。

从上一主题到我开始的整个主题中,我的贡献为2美分。

首先, @ oliverjanik,我无法说得更好。

我决定不要再从前端堆栈中移出,当我想要创建一些成熟的东西使我能够专注于业务而不是“冷静”或只是为了改变而改变时,我不能在堆栈之间跳来跳去在一天结束时有一个小改进。

所以我回到了Angular(很久以前我就在Angular 1),因为我看到了架构的变化,看起来非常棒,但是后来我碰到了墙,这对我来说是不应该的#6466,经过整整一周的尝试为了得到我所关心的问题的答案,我意识到我将不得不修改设置,并且也不会直接进行。

我只想在任何生态系统上创建最常见的用例:共享一个可重用的模块,为什么我需要修改一下

CLI旨在基于生态系统使用,我明白了,但是与此同时,已经有应该修复的通用用例,特别是在有很多人都关心的情况下。

然后更糟糕的是,您读到了类似https://github.com/angular/angular-cli/issues/1692#issuecomment -302742332的内容,这些内容让我感到非常恐惧,因为它们想要长期思考并建立整个公司在上面。

如果您(Angular生态系统的主要贡献者)不想支持您的社区(这并不意味着您根本没有这样做),请与我们保持联系。 很多人都依赖于您,有时甚至不需要花一个星期就可以实施对社区有益的巨大影响。 并非所有事情都能引起Google的兴趣,但至少要清楚。

我是从两个星期前才刚开始的人说起的,一个在React生态系统中很高兴但出于各种原因一直想回到Angular的人,一个想成为您社区的一员,并且可能加入社区的人。未来可能成为潜在的贡献者,使您的生活更轻松。

请考虑在您的社区中,它将长期取得回报,不要阅读它,对此感到难过,并以消极的心态思考,因为我无法表达我对您在Angular上所做的出色工作表示感谢,但是同时,不要让像这样的小东西变得更大。

跟我们说清楚

@yordis同意。 在我们讨论技术解决方案之前,应该在文档中提及此问题。 我创建了一个公关https://github.com/angular/angular/pull/17129

我的2美分是,对于大多数人来说,他们只需要知道创建可重用Angular模块的方向即可。 如果我们可以将@robwormald的解决方案添加到文档中,然后算上我。它现在不必是技术上最优化的解决方案,为了避免这种情况,在非最优解决方案的背后有很多价值达成共识。 在此之前,Angular是“做出重大决策,因此您不必...但是您不能重用代码”的框架。

@oliverjanik @yordis @rjsteinert感谢您的反馈。

我只想包装一个很小的组合框,然后与团队和/或整个世界共享。

我不想以任何方式最小化您在这里所说的内容,因为其中有很多好处-但是我们应该清楚,今天这绝对是可能的。 它绝对比需要的复杂,但是这里有一些很好的例子可以作为参考。

看起来很棒的是ng-bootstrap: https :

这是Jason在ng-conf上提出的包装格式指南: https :

@filipesilva还为在文档中为此编写指南做了出色的工作,并且您可以克隆一个入门级仓库,很遗憾,拉取请求被我们的基础架构转换所困扰。 我正在努力尽快将其合并。

您可以在这里看到该PR: https :
以及此处的入门仓库: https :

在这一领域缺乏标准化和缺乏指导确实在损害生态系统。

应该说,我们在这里要做的事情几乎有零先例。 仅此空间中的一些挑战:

  • JS生态系统和NPM当前没有将ES2015 +代码运送到NPM的标准计划。
  • NodeJS和朋友仍在争论节点如何加载ES模块。
  • Webpack开箱即用,不会从NPM转换代码,但是...
  • ES5代码实际上是不可摇摇的。
  • 直到大约一个月前,还没有浏览器对静态或动态加载的ES2015模块提供任何支持。
  • NPM建立在非标准的,非静态的,可分析的模块格式上,该格式对性能影响不大: https
  • 有些开发人员想要最简单的方法(将脚本放到页面中),而另一些开发人员则希望绝对自由地监视性能的每一毫秒。 这意味着前者为UMD,后者为ESM / ES2015 / 6/7。 见http://2ality.com/2017/04/setting-up-multi-platform-packages.html并注意有元-这回指角队的上述建议。
  • 从历史上看,捆绑所有代码一直是“正确”的处理方式,但是在拥有http2(push)和低功耗移动设备的世界中,这可能不是正确的前进方向!

...这一切都是在我们甚至开始谈论Angular之前! 同样,我们完全支持您,但这是一个生态系统,我们全都在此摆布。 加入Angular团队时,很明显的一点是,我们的工作确实处于最前沿–在我们前进的过程中,我们确实必须发明很多此类东西。 这是我热爱工作的重要原因,但这意味着有时候,您将不得不尝试有时无法正常工作的事情。

示例:上面文档中提到的F​​ESM格式非常适合ngrx等项目,但不幸的是,它对Angular Material等库产生了影响,因此我们针对此类情况对这些准则进行了调整。 在尝试之前,您只是不知道其中的许多事情。

我想在这里理解的一件事很重要,那就是我们(Angular团队)两次处理此问题-一次是内部的,对于使用Angular的Google和Alphabet中的所有项目,一次是FOSS社区。 为什么?

在Google,我们使用的工具集与开放源代码世界中使用的工具完全不同:

  • Blaze(或bazel.io)是我们的构建系统,用于在Google上构建从Angular到Maps到Gmail的所有内容。
  • Closure Compiler,它进行捆绑(替换Webpack),优化(替换Uglify),模块加载(替换SystemJS或Webpack)
  • 大量严格执行的约定和规则,以及用于强制执行的构建基础结构。
  • 我们有自己的特殊模块格式(闭包的goog.require)
  • 我们不使用NPM或node_modules

这意味着,运行面向开源CLI项目的@hansl正在做内部Angular基础架构团队无法共享的工作(因为我们没有使用Webpack等),反之亦然。

如果我们完全诚实地说,这种情况以及今天存在的CLI的内部都是不可持续的。 有了ember-CLI项目的出色支持,并利用

这并不出乎意料,这也是我们一直坚持不公开Webpack内部的原因-我们知道在某个时候,我们必须还清技术债务,而我们想这样做而又不暴露开发人员搅动。

DevKit项目的想法是最终允许我们在内部和外部客户之间共享工具-意味着@hansl和co不会重复工作,令人兴奋的是,Google团队的开发人员可以帮助改善相同的工具,包括开源Angular开发人员使用。 @alexeagle已经写了一些有关此的内容-https : //medium.com/@Jakeherringbone/what -angular-is-doing-with-bazel-and-closure-21f526f64a34-我们已请求并帮助Typescript团队设计功能(如变压器管道)最终将解锁进一步的代码共享并简化我们的TS工具。

如果您不关心它的工作原理,那么您就不必关心它的工作原理。 但是,它将允许想要的开发人员构建和扩展工具链,以执行各种强大的任务。 作为一个方便的例子-我们与许多希望为其内部包装使用标准样板的团队进行了交谈。 DevKit将启用该功能-而不是采用修补的方式,而是从一开始就将其纳入设计。 是否要插入生成管道并将您自己的自定义许可证添加到每个生成的文件? 当然。

所有软件都是要权衡取舍-我们很早就做出决定,为希望成为高效构建应用程序的开源开发人员提供一种可以立即使用的工具。 我认为,除少数例外,我们已经实现了这一目标。 我们正在努力做到这一点,同时还要平衡长期的可维护性,并为Google的团队交付薪水(以及我们出色的承包商的薪水),并使整个Angular项目成为可能,而且只有几个小时在白天!

如果您想在此处进行其他说明,请随时询问。

@robwormald我不明白为什么当有数千个使用Webpack构建的库示例时,您为什么说问题是Webpack

我完全同意@oliverjanik ,这是无法理解的,Angular团队对此没有给予优先考虑。 您不能建立基于不允许重复使用组件的组件的框架。 这是完全荒谬的。

在我们的开发团队中,当我们开始与Angular合作时,我们要做的第一件事就是为我们所有的模块创建一个可重用组件的库。 Google没有以同样的方式思考是没有道理的。

我们还能够轻松创建可重复使用的组件,例如组合框。 如果您有兴趣了解我们的项目是这样的:

https://github.com/Stratio/egeo

由于我的误解,如何处理此问题的两个主要问题。

  1. https://github.com/angular/angular-cli/issues/6466基于该问题,为什么当我只想拥有NgModule并使用CLI时,CLI为何强制我具有引导应用程序在这种情况下运行测试。
    我不明白为什么现在这么大,在运行karma测试时,由于某种原因,在抱怨某些代码分析之前,某些原因已经停止,我不知道为什么。
    用例非常简单。 3个应用程序。 可重用核心功能的第一个应用程序。 github page版本的第二个应用程序。 开发测试的第三个应用程序,例如用于视觉测试的鸡水槽,几乎就是material2所需要的,而无需任何大吃一惊或任何其他设置。

在没有任何special case情况下,我们需要做什么来解决该用例? 因为到目前为止,只有一个问题

  1. 如果我们仅将Angular项目推为Typescript项目而不是Javascript,会发生什么情况? 您提到了Webpack不能从node_modules ?开始编译! 我上次检查时实际上必须将exclude过滤器放置为node_modules以阻止这种情况的发生。 对?!

请保持简单。

现在我们有了Angular Package Format ,我们需要一个projection: (entryFile: string = 'src/public_api.ts') => NgPackageFormat

interface NgPackageFormat {
  main: string,
  module: string,
  /* ... */
}

它不仅需要一个输入属性,而且需要一个工作流,以便从源代码创建该Angular Package Format。 我同意@robwormald的观点,即单元测试支持是主要部分。 减轻手动配置几个构建步骤的负担将是下一步。 我现在不在乎第二步和第三步。 您将失败,并且ng cli在执行大型“库开发人员模式”中失败了将近一年。 请做出一个决定。 做一个步骤。

-编辑:我为大胆的措辞辩解。 请让我们专注于逐步改进。

@pjpenast,请阅读软件包格式doc ,因为它涉及很多内容,但是我摘录了重要的一点:

在当今的JavaScript环境中,开发人员将以许多不同的方式使用软件包。 例如,有些可能使用SystemJS,有些可能使用Webpack。 还有,其他人可能会以UMD包或通过全局变量访问的方式在Node或浏览器中使用软件包。

Angular分发包支持所有常用的开发工具和工作流程,并强调优化,这些优化会导致较小的应用程序有效负载大小或更快的开发迭代周期(构建时间)。

尽管此线程中的每个人都可能使用角度CLI,但由于种种原因,我们的用户群中有很大一部分不是或不能。 如果我们要有一个官方支持的工具,它不能排除任何使用webpack的人。

您不能建立基于不允许重复使用组件的组件的框架。 这是完全荒谬的。
Google没有以同样的方式思考是没有道理的。

Google内的许多团队都使用@ angular / material,并且它们之间共享自己的组件-但同样,它们都没有使用webpack或您使用的任何工具-他们都使用闭包编译器,而不会使用闭包编译器接受webpack输出! 我们从源头编译所有内容-这只是一个不同的环境。

在我们的开发团队中,当我们开始与Angular合作时,我们要做的第一件事就是为我们所有的模块创建一个可重用组件的库。

大! 也许您可以在博客中介绍您的解决方案,或者与Angular社区分享您学到的知识,或者写下您的发现并与我们分享?

@dherges在进一步发布之前,请参阅《行为准则》 。 欢迎提供反馈,但请保持反馈。

现在我们有了Angular Package Format,我们需要一个投影:(entryFile:string ='src / public_api.ts')=> NgPackageFormat

从高层次上讲,这正是DevKit的目的。 我们不能简单地添加到现有的CLI上。 在此期间,上面链接的实现这些模式的种子/启动程序项目似乎是一个合理的第一步。 参见https://github.com/filipesilva/angular-quickstart-lib。

@robwormald我知道有很多不同的框架,因此您必须尝试将它们全部改编(SystemJS,Webpack,Rollup等),即使在Google中,您所拥有的框架也不同于所解释的社区,这是我的问题视点。

但这问题存在于所有Javascript库和框架中,并不一定带来不便,这会阻止您接触社区,并使人们更容易在Angular中进行开发。

Google内的许多团队都使用@ angular / material,他们在彼此之间共享自己的组件。

是的,Angular Material是Angular中可重用代码的一个很好的例子,我们已将其用作我们库的参考。 但这是一个相当复杂的解决方案,并不容易实现。

Angular生态系统中的问题不是不可能创建可重用的代码库,而是已经做到了,问题在于它不容易实现。

大! 也许您可以在博客中介绍您的解决方案,或者与Angular社区分享您学到的知识,或者写下您的发现并与我们分享?

在我的团队中,我们很乐意与社区分享我们如何在Angular中建立组件库的知识。 您能告诉我分享这些知识的方式吗?

谢谢!

我认为不听取社区的意见是一个很大的错误,我认为如果您可以问所有人,大多数人都会同意建立可重用组件库的官方方法是必要的。 至少Angular团队和角度材料团队可以将有关角度材料如何实现这一目标的文档编成简单指南。

我使用@pjpenast进行工作,正如他

他们使用Typescript编译器的角度包装器来创建d.ts和metadata.json,使用Rollup创建包,并且使用元数据和javascript生成文件中的内联文件内容替换对html和样式文件的引用。

我们假设Angular得到了像Google这样的重要公司的支持,我们假设Angular拥有出色的支持服务和社区,最重要的是,我们假设Angular渴望成为做可重用组件的最佳框架,那么没有理由不这样做。在框架稳定运行了一年之后,有了开发图书馆的官方方法。

该线程中一个可立即执行的项目似乎是文档,并链接到库种子项目。 我认为可以公平地说,创建库并不像人们希望的那样简单明了,但肯定是可能的。 我们应该努力使事物保持建设性,减少双曲线。

@hansl是否可以构建工具并与cli生成的项目一起使用来创建库? (使用.angular-cli.json文件获取信息)不确定是否可以提供比完全独立的种子项目更好的解决方案?

ng new my-lib && ng-lib ./my-lib

w00t!

@filipesilva您的文档PR似乎是一个不错的开始! 太糟糕了,它被滞留在aio文档站点的基础架构升级之后。 我敢肯定,在这个问题队列中会冒出很多烟,一旦发布就会消失。 我期待着https://github.com/angular/quickstart-lib

@robwormald非常感谢您指出PR,更不用说NG Conf上有关如何打包Angular库的演示了。

@deebloo @hansl您能指出一些有关如何在Angular CLI中创建新生成器的文档吗? 我有兴趣将quickstart-lib滚动到生成器中。

@hansl对于

@robwormald感谢您提供了更周到,更详尽的答复

对于着迷于此问题的人们,即使它不存在,也可能会指向文档PR。

我的意思是,如果对第一条评论进行更新以总结所采取的措施,那么对解决此问题的人们将有所帮助。

@deebloo我不会推动其他命令或任何其他现实中应该存在于ng

角队,
看看您的Polymer合作伙伴,由于npm的限制,他们要求bower ,每个人都讨厌它,但同时也不在乎,因为它在一天结束时仍然有效,并且向您展示到处都是怎么做。 无需阅读3页长的某些规范或类似内容,他们的策略包括简短的视频以及与社区的大量互动,文档等,以及工具备份。

从那里得到的一些好处是,您不必适应Javascript社区中的所有内容,但是如果您不教我们如何提高生产力,请关心我们,我们如何使用Angular。 如果我愿意为创建者提供支持,并且在不阅读技术论文的情况下找到答案,那么我对任何架构和生态系统的转换都很好(不,因为我不知道,我排除了实际上不了解的人,但是因为我堆栈上的详细信息应该离我尽可能远,甚至包括Typescripts配置)。

顺便说一句,信息可能在那里,但我们未能将其发布。

@deebloo就是ng-packagr的意图。 还有一个演示并排显示ngng-packagr

@dherges是Angular CLI使用的吗? 我试图在Angular核心团队中推广这种工具。 他们应该做这项工作,IMO

嗨,大家好,

在完成大量工作以整合可靠的构建过程之后,由于社区的需求,我最近将其转换为通用存储库。

经过一番探索,我发现这些是库模板应提供的关键功能:

  • 作用域( npm install @my-scope/my-lib

  • 多个库存储库( @my-scope/my-lib@my-scope/her-lib ,...都在同一存储库中)

  • 软件包扩展。
    带有可选内部软件包(例如@angular/core/testing ),扩展名的装运软件包是单独构建的。

  • 构建钩子,点击以更改package.json,tsconfig,汇总配置等(全局和每个包)

  • Webpack驱动

  • 输出:

    • 展平ES模块(ES5,ES2015)
    • 汇总UMD软件包+精简版+压缩版
    • 源地图,完整而准确。
  • 通过metadata.json文件的Flat Angular编译器模块。

  • 资源内联(html,css,scss),以获取源代码+ metadata.json

  • 由webpack驱动的资源内联,无模糊任务,请使用您喜欢的webpack加载程序。

一些不错的附加功能:

  • 专用的演示应用程序,编写时就好像您的库是一个模块(没有相对导入)

    • 仿真模式-在dev或prod模式下,在prod编译库上运行演示应用程序,就像在node_modules中一样。

模拟实际上是一件大事,它可以针对已编译的已发布版本的库运行演示应用程序,在该版本中,演示可以是JIT然后是AOT。
这是运行E2E测试并验证发布(即将发布)版本合法的好地方。

演示应用程序上的E2E单元测试更针对课程库,而不是演示应用程序。


为了使这项工作有效,需要在@ngtools/webpack进行一些更改。
这主要涉及在AOT插件中提供挂钩以进行集成。

我在ngc-webpack实现了这一点,这是一个轻便的compiler-cli包装器,允许使用这些钩子。 ( ngc-webpack提供AngularClass / angular-starter中的AOT集成)

该插件将在AOT编译器加载资源时通知,这可以保存资源以供将来内联。 (lib是使用skipTemplateCodegen false生成的)

这里的巨大好处是,我们不需要大口大口或其他任何过程来管理我们的资源。 本机处理的,这是一个确保一致性的无缝过程。 (例如SCSS,postCSS等)

@hansl我知道@jskrzypek基于我在ngc-webpack所做的工作开始与tou谈论


我上面列出的所有功能(以及演示和模拟)都是我前面提到的库启动器存储库的一部分。

您可以在此仓库中查看它: https :

它工作得很好,并且有一些示例,您可以在其中看到输出,它的输出与角度包相同,并支持UMD,FESM(es2015 + 5),摇树等。

一个很好的例子是带有内部扩展(例如@angular/core/testing )的范围多库项目,我称其为扩展/插件。

范围: @corp

有3个库和2个扩展:

  • @corp/core

    • 扩展名: @corp/core/testing
    • 扩展名: @corp/core/plugins/core-plus
  • @corp/common

  • @corp/rare

这是一个很好的例子,因为它演示了构建具有相互依赖关系的复杂结构的能力,以及在捆绑时如何处理它们(外部和全局汇总)


坦白说,如果我们可以将其集成到CLI中,那么我不是初学者,我很乐于帮助将其集成到CLI中。

cc @shairez


编辑:从理论上讲,如果我们实现了以上的角度项目,材质等,都可以使用cli,它与用TypeScript编写的TypeScript远程相似:)

@shlomiassaf我真的很喜欢构建钩子和程序包的库内作用域的想法。

当前,在Angular Librarian上,我们具有您提到的许多功能以及一些轻型脚手架功能(初始化项目,组件,指令,服务),并且非常好地将其中的一些功能集成到其中。

我知道这不是官方的Angular CLI,但是我正尽力在此同时填补空白。

所以我给了https://github.com/filipesilva/angular-quickstart-lib一个镜头。
在玩了一天之后,我的结论是它还有一段路要走。 这有点干,我不喜欢依赖systemJs和Rollup。 虽然汇总可能会产生较小的捆绑包,但我沉迷于复杂的技术中,因为我没有时间充分了解这些技术。 有时会产生模糊错误的技术人员。

因此,我对来这里寻找模块捆绑解决方案的人们的建议是等待一会儿。

现在使用npm link

我的2c。

@larssn我的猜测是这些错误主要与捆绑有关,更具体地说是定义外部和全局。

恕我直言,这在CLI实施中也不会改变,您将必须为库构建过程提供正确的配置。

虽然很有可能自动发现external条目,但全局变量的可能性较小,如果要支持UMD捆绑包,则必须提供它们。

无论如何,建立图书馆被认为是高级的,我相信会有一些知识。

@shlomiassaf是的,错误主要与之相关。 我会修复一个,然后会弹出一个新的。 我面临的挑战是为json提供import支持。 除了测试以外,大多数情况下它都能正常工作,这是我现在放弃的地方。 也许能够解决它; 但是其中一部分是回顾快速创建可重用库所涉及的工作; 我不相信这一点。

@larssn发生这种情况是因为您必须声明第三方进口。 对于每个唯一的导入令牌,您需要一个外部声明,用于FESM。 对于UMD,还需要声明全局名称。

因此,如果添加import { Observable } from 'rxjs/Observable'; ,则需要确保声明

外部: rxjs/Observable
全球: Rx

external很简单,这就是为什么它可以自动化的原因。
globals是自定义的,作者决定UMD捆绑包将在全局(例如,窗口)对象中注册的方式。

其他例子:

rxjs/operator/combineLatest - Rx.Observable.prototype

@angular/common - ng.common

维护起来并不难,特别是因为汇总会通知缺少的内容。

对于Angular世界中十分之九的库,这些配置可以并且应该提供现成的已知值。

无需将rxjs和@ angular / *软件包的汇总配置从一个种子复制粘贴到另一个种子,再复制到另一个启动器...当我们尝试一步一步地改进时,这很简单。

嗨,大家好,我写了一个建议,说明现在如何在Angular CLI应用之间共享Angular模块。 我称之为__NG Remix__,它有两个原则。

  • 原理1-所有Angular模块均未编译
  • 原理2-Angular模块共享NPM依赖性

在我的提案中,我讨论了如何应用这些原则,优点和缺点,还包括有关ng-remix CLI的规范,该规范可以帮助您消除体力劳动。 我对乡亲的反馈意见很感兴趣。 当然,这两个原则并非对每个人都适用,但是如果它适用于我们,那么说千个Angular开发人员中的50%,我会说这会刺激很多共享。

在此处查看提案-> https://gist.github.com/rjsteinert/82b3000037a5672f43a4d15313ac613f

@robwormald我对您将种子库方法与我上面建议的NG Remix方法进行比较的想法感兴趣。

@rjsteinert反馈:

  • 在这种情况下,“未编译”是什么意思? 正确地将Typescript运送到外部世界是一件非常非常困难的事情-任何想要使用您的库的人都必须能够在其末端重新创建整个Typesystem /环境。 我们很早就对此进行了探索,但似乎还没有开始。

  • 为什么凉亭会进入这个? 甚至Bower的作者都说这已经死了,添加另一个包装管理器似乎是个坏主意。

我想我不太清楚您的方法是什么?

@robwormald

任何想要使用您的库的人都必须能够在其末端重新创建整个类型系统/环境

我相信这就是ng-cli的特长:-)。 成为cli-cli创建的应用是一项艰巨的要求,我可以在该建议中更清楚地说明这一点。 现在,这也使我意识到,这些模块最终将需要指定它们所基于的ng-cli版本。 注意,像我这样的人__angular-cli是Angular Framework__。 如果框架是一堆捆在一起的东西,那么angular-cli@angular/angular更适合该描述。

为什么凉亭会进入这个?

大声笑,是的,令人惊讶。 有人建议由罗布·多德森在谷歌I / O呈现在Web组件的情况下与角使用权在谈这一点。 其原因是“平面安装”。 例如,为什么我们要使用同一模块的两个不同版本来定义完全相同的路由? 当两个模块定义相同的依赖项但版本不同时,Bower帮助您进行分类。

@robwormald您的问题更新现已添加到提案中。 谢谢参观!

这里的最后几个讨论再次强调了使用小型,专注的工具来完成工作的意义。 尽管种子和入门包是一件好事,但问题是:它们如何与ng CLI或自定义Webpack构建,或bazel或_how-does-YOUR-set-up-look_一起使用?

同样,我认为应该以Angular Package Format格式插入public_api.tsdist文件夹。 作为一个好的开始,应该支持buildtest这两个命令!

# Build the library
$ <angular-library-build-tool> build -p <library-conf>.json
# Run unit tests from *.spec.ts files
$ <angular-library-build-tool> test -p <library-conf>.json

接下来是dherges / ng-packagr#5的议程!

好吧,在阅读了#1692和本期之后,我完全不知道现在使用哪种方法来创建库。 为了尽快解决问题,Angular / Angular-ci团队会提出自己的解决方案。
最广泛的方法似乎来自@shlomiassaf网址
但是,在我的情况下,我真的不需要“在一个仓库中有多个库”的方法(尽管我了解它的存在)。

那么该选择什么:
https://github.com/filipesilva/angular-quickstart-lib
要么
https://github.com/shlomiassaf/angular-library-starter
要么
https://github.com/jvandemo/generator-angular2-library
或查看他们是如何做到的:
https://github.com/ng-bootstrap/ng-bootstrap

而且,如果您只是尝试在Internet上找到解决方案(就像大多数人一样),则可以使用诸如http://www.dzurico.com/how-to-create-an-angular-library/https:// github的教程

当您拥有资源(scss和图像)或想要构建本身依赖于库或框架(例如bootstrap或zurb基础)的库时,它会变得更加复杂。 我完全理解@oliverjanikhttps://github.com/angular/angular-cli/issues/6510#issuecomment -305050324并且应该有一些官方的反应如何做才能填补了国内空白。

@Flixt有关最基本的设置,请参见ng-conf上的演讲。 演讲的示例在GitHub上也可用,因此您可以看一下。 它不是花哨的(不需要很多东西),但是它可以工作,让您快速入门。

@Flixt我想指出的是https://github.com/gonzofish/angular-librarian也在那里-类似于generator-angular2-library

这是一个在制品,但它一直在为我的日常工作

@ devoto13如何处理组件内部的外部模板?
谈话中提到的simple-ui-lib使用内联模板。

@kkganesan当前,我仅使用内联模板和样式。 不是很方便的选择,但目前可以使用。

我喜欢https://github.com/filipesilva/angular-quickstart-lib的制作方式,因为它建立了可纠正角度模块格式的库,并且具有在jit和aot模式下运行的集成测试,但是它使用了笨拙的SystemJs。 我在这个简单的库项目https://github.com/anjmao/ang-select中重写了开发构建过程,以将Webpack用于演示应用程序和单元测试

@robwormald对此有任何更新吗?

大家好。 只是想与您分享一种适合我当前正在工作的公司的解决方案。 我设法使cli成为具有多个应用程序和模块共享库的单一仓库。 当前设置支持延迟加载,AOT,SCSS和共享模块的自定义路径(“ @ shared /”)。 尽管此设置被认为是黑客,并且可能不遵循Angular软件包格式,但它确实满足了我们的需求。 它很容易使用,因为您可以有多个可以独立提供/构建的应用程序,它们共享您的自定义组件和相同的node_modules。 基本的回购结构是:

  • src
    -app1
    -app2
    -等
    -分享
    - - - 组件
    ------提供者
    ------等
  • dist
    -app1
    -app2
    -等
  • node_modules

请求后显示设置的仓库

我确实要感谢Angular团队提供的这个出色的框架,因为我每天都喜欢使用它。 继续出色的工作:)

感谢您分享您的解决方案@nekkon
您是否有一个GitHub存储库显示此结构的设置?

在几个请求之后,我已经更新了Github存储库,使其具有更多功能:

具有库支持的Angular CLI(1.2.7)

该项目是使用Angular CLI生成的。 它是使用ng new生成的新应用程序的扩展版本。 它在单仓库中增加了对多个应用程序的库支持。

此启动程序是许多解决方法的结果,目的是使Angular-cli与组件/服务/模块等共享库一起使用。

目前支持:

同时提供多个应用
多个应用的​​生产版本(使用AOT)
组件/模块的共享库(可以在每个应用之间通过@ shared /共享)
共享资产文件夹和polyfill。 (可以在每个应用之间共享)
共享的SCSS。 (可以在每个应用之间共享)
延迟加载共享模块
每个应用程序的单元测试
每个应用程序的端到端测试
自定义命令使您的生活更轻松
以及您通常可以使用ng new生成的应用进行的所有其他操作。
随时为请求创建问题或解决问题。

如果愿意,请为该项目加注星标并提供支持,以帮助其存活,甚至可以作为样板/启动器添加到angular-cli(例如新的应用程序名称--template库)中。

@hansl Angular团队对此有何更新?

@yordis @piernik @desfero @RSginer @samherrmann @benjamincharity @gracegotlost @ rafmagns-skepa-dreag大家好。 直到角CLI队正式为您提供了一个库选项,您可以尝试一下。 随时提供反馈,提出要求或报告问题。 我会不断更新它,因为我在工作中使用它。 (当前版本1.3.2)

@nekkon只是为了理解... angular-cli-library通过Type compilerOptions.paths共享来自TypeScript的通用代码,对吗? 因此,实际上,每个应用程序都链接到源并重新构建shared库。 然后, shared库不打算在npm注册表上发布,对吗?

@dherges “ angular-cli-library共享来自TypeScript来源的通用代码”->是。 它使用位于应用程序中或来自库(共享代码)的src文件夹中的模块/代码。 如果需要,该库也可以发布在npm注册表上。 我可以在仓库中添加一个示例。 因为我不想污染此主题,所以请在回购中提供反馈,提出问题,提出要求或报告问题

@nekkon是和否。 如果发布到npm注册表,则应采用Angular软件包格式,这涉及一系列不同的构建步骤和工具。

@dherges该库可以发布到npm注册表。 我添加了一个示例,其中共享库是从npm注册表导入的(Example2)。 导入的模块可以延迟加载到其他项目中,并且与aot兼容。 以我的理解,这个线程正在谈论一个可以导入其他项目的库。 我不懂你。 为什么图书馆需要构建步骤和工具?

@nekkon

@yordis我可以做类似的事情,但要花费一些时间来制作视频。 我会尽量在周末找些时间。

精细!

我主要是在谈论角度包格式,这是发布库的推荐方式-与发布源文件相反,而将源文件留给打字稿编译,模板语法和类型检查,样式预处理(如供应商前缀或scss / less预处理)到构建工具lib消费者。

干杯,大卫

2017年8月24日,22:44,Nektarios [email protected]写道:

@dherges该库可以发布到npm注册表。 我添加了一个示例,其中共享库是从npm注册表导入的(Example2)。 它也可以延迟加载到其他项目中并且与aot兼容。

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件,在GitHub上查看,或使该线程静音。

@dherges谢谢。 我将添加您提到的内容(打字稿编译,模板语法和类型检查,样式预处理,如vendor-prefixing或scss / less预处理),尽管它可以用于大多数用例。

当人们谈论添加库支持时,他们通常是在谈论预编译步骤并以这种方式使用它。

只想添加我的用例,我们需要未预先编译的共享代码。 我们希望能够提供消耗Images和SCSS变量的Core组件。 根据所提供的应用程序,提供给这些核心组件的SCSS变量将有所不同。

我们有一个白色标签的网站,然后大约有10个“皮肤”,“品牌”或“主题”,只需要更改颜色和图像即可。 假设您需要创建2个应用程序:“可口可乐”和“百事可乐”。 唯一改变的是颜色和图像。 尽管我认为我们可以用monorepo来实现

@intellix我最近在Angular monorepo的项目脚手架上进行了实验。 生成的项目具有类似于Angular repo或Lerna提出的结构的结构,从而有助于

  • 在monorepo中建立图书馆
  • 从功能包构建应用

我在#6083中概述了我采用monorepo方法的主要动机但在这里重复一遍 。 (编辑:请参阅下面的更好的解释)

@intellix我出于您提到的相同原因,也将主题视为独立的程序包。 生成项目时,您也可以选择搭建主题包。

从我迄今所看到的,我可以通过@dherges打造包推荐NG-packagr符合性以角封装格式(无企业经验在这里,虽然)。

TypeScript刚刚为包含node_modules的符号链接存储库推送了一个修复程序,并且无法将类型解析为相同: https :

我推送了两个可以同时使用angular@nexttypescript@next

蓝色CLI依赖于红色CLI,并使用其中的组件。 我只在本地引用了angular-cli-red,因为它们尚未发布: "angular-cli-red": "file:../angular-cli-red"所以结帐像这样:

angular-cli-red
angular-cli-blue

由于@dherges的ng-packagr,在CLI开始能够构建组件库之前的潜在解决方案: https ://medium.com/@ngl817/building -an-angular-4-component-library-with-the- angular-cli-ng-packagr-53b2ade0701e

@nikolasleblanc作为一个停顿

我已经在这个线程中说了几次(我讨厌自我推广,但我再说一次),我一直在从事一个名为Angular Librarian的项目,该项目对我的团队非常有效。

它具有所有您期望的CLI支架和使用Angular Package Format的捆绑

我真的很尊重@dherges对ng-packagr所做的工作以及它与CLI的集成,但始终希望为人们提供选择!

@gonzofish您和@dherges可以一起工作以合并那些项目吗?

那可能是最好的解决方案,不是吗? 我会做游戏,我认为与CLI集成可能是更符合人体工程学的选择

@gonzofish似乎是一个不错的目标,但听起来好像CLI可能会更改以与DevKit集成,所以在当前状态下与它集成是否意味着事情变得很脆弱? 我现在找不到它,但是我认为Angular团队可能已经向@dherges表示他们也不希望将其放到1.x中。 我不知道答案,所以很想听听Librarian和ng-packagr当前的工作以及两者之间的区别。 @dherges可能必须让我们对他遇到的目标/权衡有所了解。 无论如何,除非你们两个都愿意,否则我不想成为中间人。 作为希望使用这些工具的人,我可以看到在将Angular库打包为dev-devkit打包时,在其他零散的环境中达成共识是有帮助的。

这是有关该工具的动机和ng-packagr用途的设计文档。 将其视为(entryFile: TypeScriptSource) => AngularPackageFormat 。 您可以将其与周围的任何其他构建工具集成。 没有官方支持,但是GitHub问题也是文档的来源。

角CLI有库开发模式,现在1年,以及在公告。 我在Angular CLI中没有“赌注”,也无法代表Angular团队发言。 我不知道他们的计划是什么。 我只是说说我的主观感受:-)

当您在不同的位置运行多个开发团队时,您将拥有一个通用的工具链。 最终,Angular CLI帮助我们在构建应用程序方面提供了很多帮助。 除了{{现在选择任意数量}}源代码存储库之外,没有人希望维护高度定制的构建脚本。 对于库,我们现在也有一个解决方案。 我们可以靠自以为是的工具及其几种最佳实践配置来完美地生活。

Nx看起来很酷,但我不认为它完全可以解决图书馆的问题。 它实际上只是将所有内容放入monorepo中,因此您实际上不必解决库问题,对吗? 将您的整个公司归入一个仓库根本无法为许多组织所用。 要管理的团队/人员和发布太多,涉及太多的政治。 这个问题是更多的生成可以导出(并推到NPM,例如),并导入到其他应用程序(在其他回购)独立库-这一切都与最佳实践(捆绑,缩小等)做这件事,并配套以及开发人员的经验。

的确,Nx有点过大,再加上除了一些大型企业外,几乎没有人从事过单购回项目。 我们只希望Angular CLI以库模式初始化项目,那就太好了。

将您的整个公司归类为一个仓库根本无法为许多组织所用

除了一些大型企业以外,没有人从事单一回购项目

@ Matmo10 @avatsaev我想你错过了重点。 Monorepos可能对于构建库不是必需的。 但我认为他们是重要有利于图书馆在应用开发过程中的出现。 我发现Nx描述的故事几乎与我从自己的经历中分离出来的故事相同并且这里这里得到了巩固。

Monorepo不一定意味着要在一个大型仓库中开发公司的所有库(尽管据说Google,FB等是这样做的),但也不必在同一仓库中从多个较小的程序包中开发一个应用程序。 我认为,应用程序开发和库开发是同一方面的两个方面。 做对了,应用程序开发一个孵化新库并重用现有库的过程。 甚至小型公司也开发大型应用程序(最好说应用程序),并且需要实践重用才能提高竞争力。 他们需要保持构建基块的简单和集中,以扩展其系统,而又不增加在相同规模上理解它的精神开销。

因此,我们假设另一个项目的同事问您是否解决了应用程序的日志记录问题。 我可以想象团队会说,是的,我们已经解决了。 是的,我们已经解决了。 npm install foo-logging (更具吸引力)。 我什至可以看到同一团队为Next-Important-Big-Customer项目复制内容,并且可以想象同一团队仅从上一个Important-Big-Customer项目安装他们自己的日志记录库。

不幸的是,到目前为止,使用Angular和Angular-CLI,我已经看到很多模仿者开始摆弄相对的导入路径,一旦有人要求重用此功能,它们就会从CLI生成的应用程序中提取日志记录服务,ngModule和其他内容。然后。 他们可能不喜欢monorepo方法,然后决定将日志记录部分放入单独的repo中,好吧。 问题是为什么他们从一开始就不这样做?

以我的经验-如果您的项目结构鼓励人们独树一帜,并且模块化的成本像今天一样高昂而复杂,您将不会让人想到模块化。 如果人们必须为每个程序包设置和签出单独的存储库,那么他们甚至必须为每个程序包设置构建脚本,那么,既然为角度创建一个lib是一件很痛苦的事情,那么他们根本就没有足够早地这样做。 模块化将是事后的想法。 将模块切成模块要比从一开始就做就困难得多,并且通常甚至比仅仅复制周围的内容还要困难(不幸的是,除非您弄清楚N的真正含义以及它与意大利面条的关系,否则YAGNI听起来总是很酷的)。

因此,您想使用软件包开发应用程序,但又不想像使用软件包那样将代码库散布在尽可能多的存储库中。 那就是一个项目可以从monorepo结构中受益的地方。 如果它包含对其他团队有用的软件包,那么您可能决定在其生命周期的某个时候将该软件包移至单独的存储库中。 例如,如果您想将维护工作分散到所有使用lib的团队中(公司文化!)。 但是,首先重要的是想象这个特定的程序包,其次是保持实现它的成本很小,而只有第三步是将其移至另一个仓库中。 Monorepos在所有这三点上都有帮助。 第三步:当您始终按包名称导入foo-logging而不是其在存储库中的位置时,不必调整大量相对路径。 如果您始终像普通的npm软件包一样导入自己的软件包,那么将其移至另一个存储库中可轻松应对,对孵化器应用程序的影响最小

据说,我认为monorepo支持不是库支持的必要条件,但它确实可以在应用开发过程中帮助库出现。

一个根本不需要monorepo! 💯

甚至可以将npm软件包发布到私有git仓库和npm install | 来自git网址的yarn install ! 即使是棱角分明的建筑

一个根本不需要monorepo! :100:

@dherges即使撰写有关monorepos的好处的文章,我也可以支持。 能够使脚本在包文件夹迭代构建过程中喜欢用NG-packagr刚好够我的那一刻:笑脸:(优化版本,支持范围的包在这里)。

我认为这里没有提到它,但是根据官方博客文章https://blog.angular.io/the-past-present-and-future-of-the-angular-cli-13cf55e455f8

CLI的未来
使用CLI的团队有许多计划可以使开发人员的生活更加轻松。 以下是团队希望(但不保证)在将来的发行版中包含的一些想法:
[....]
库支持-如今,CLI可以生成针对浏览器优化的UMD,以及针对服务器优化的CommonJS捆绑软件。 如果CLI可以帮助您产生可以被其他Angular应用程序使用的捆绑包,该怎么办?
[...]

我们正在制作一个简单的用于生成库的命令工具。 您只需传递要成为库入口点的ts文件:

ngmakelib src/library.entry.ts library-name

这会创建一个tar.gz,您可以直接在npm install中使用它。

目前仅导出FESM模块,该模块适用于我们的所有用途,可在其他Angular项目中重复使用。

通过在CLI项目中安装此工具,您可以将其导出为库以在其他项目中使用。

您可以在这里看看:
https://github.com/fintechneo/ngmakelib/

https://github.com/dherges/ng-packagr使用FESM2015,FESM5和UMD格式做到了这一点,但在某些用例中已被打破,但是Angular的4.4.5版本解决了该问题(https:// github。 com / angular / angular / pull / 19579),今天关闭了票,我已经测试过,现在可以正常使用了https://github.com/dherges/ng-packagr/issues/101

Angular库有很多不同的方面。

  1. Rob说要区分二进制文件和库-现在让我们使用这个术语!
  2. Monorepos和Nx工作区确实支持“库”:所有内容都在一个源代码存储库中链接,因此每个应用程序都可以从源代码构建库-而且,这种monorepo的趋势还在不断发展……🚂
  3. Angular Package Format用于将“二进制文件”分发到npm注册表:该库是在发布之前从源代码构建的。

我想说,您需要首先回答您的工作流程是(还是您希望自己的工作方式)?!

当您拥有...🎉时,最后一步是确定要使用的_what_工具。 有很多东西,您必须决定要花多少钱才能了解“一周最喜欢的工具”的细节,😂

下一个有趣的问题: ng CLI的方向是什么? 他们是否有计划支持Angular Package Format? 还是原理图/代码脚手架是主要的方式,从而告诉并假设使用monorepo? 这是混合方法吗?

@dherges我非常尊重您的工作,这听起来让我听起来像个聪明人,但是我认为您误解了Rob在写信时的意思:

在Google,我们为此使用“二进制”和“库”这两个术语:

  • 二进制文件是可移植到浏览器的工件,它是“自我执行”的
  • 库被设计为供二进制文件(或其他库)使用

如果我错了,也许@robwormald可以加入。 但是我确信将库从其源代码构建为Angular Package Format不会像Rob所指的那样使其成为二进制。

Angular Package Format用于将“二进制文件”分发到npm注册表:该库是在发布之前从源代码构建的。

让我们坚持使用APF文档,并继续说说其分发包/库的格式,该包/库支持最常见的使用模式以及Angular应用程序要使用的其他要求。 APF文档中的任何地方都没有使用二进制一词。 符合APF的npm程序包不需要是可交付给浏览器的自执行程序包。 在许多情况下,它们将成为诸如Material UI之类的组件库,这些组件库决不意味着独立于应用程序执行。 该应用程序是二进制文件

Rob说要区分二进制文件和库-现在让我们使用这个术语!

他在Google表示,他们确实采用上述方式进行区分。 我不会把它当作采用Google内部术语的建议,而只是作为Rob的解释。 术语“二进制”在JavaScript上下文中并不是不言而喻的,没有解释就充其量是误导。 最后,我很确定我们在谈论图书馆支持时可以跳过任何“二进制”措词,我主张这样做是为了避免混淆。

这是我在单存储区(如Victor所解释,并在Nrwl nx工作区中使用的示例)的上下文中对术语“二进制”和“库”(如Rob所提到的)的理解。

如果我弄错了,也许罗伯或维克多可以帮忙。 但这听起来很像上面,因为FESM软件包在浏览器中是自执行的。 您看不到任何输出,仍然可以将JavaScript复制并粘贴到浏览器的控制台,它将执行说明。 同样,从这个角度来看,UMD捆绑包和IIFE都是自执行的。

该问题创建于2017年5月31日,我们仍然没有任何官方可行的解决方案:(

@robwormald您是指将Angular组件打包为Web组件的超级功能吗? https://twitter.com/robwormald/status/916748096511500288

如果是这样,也许这是该问题的重大胜利?

老实说,我相信缺少使Angular Libraries变得简单可靠的解决方案会使开发人员脱离框架。

现在有一个不同的解决方案,所有的解决方案都在不同的角落情况下大败,而Angular CLI仍然无法提供可靠的库模式。 我从第一个Beta版开始就是Angular开发人员,这是让其他开发人员和我最大的挫败感。

制作易于构建角度库的工具现在应该是NUMBER 1 PRIORITY ,而不是Angular 5,不是Angular Universal,不是RxJS 5.5 / 6兼容性,不是PWA,而是Angular组件库。

Nx工作区非常出色。 我有一个示例,该示例使用具有延迟加载和核心模块等功能的多个应用程序: https :
现在我的最后一个问题是,编译器cli不希望在2个以上模块中声明组件,如果您仅通过导入所需的组件来替换组件,则可能会发生这种情况。

@avatsaev似乎不必要地苛刻。

开发人员已经创建了大量的Angular库,这些库必须努力工作才能弄清楚如何以困难的方式创建组件库。 由于他们的努力,有一些工具可以使开发这些库更加容易。 如果这些工具“在做铺垫”,那是因为它们需要帮助。 因此,找出问题所在,提交PR,然后进行修复。

当CLI准备正式支持库时,我们都可以将其关闭并继续操作,但是在此之前,让我们吸取知识并互相帮助。

我知道我一直在争取角型图书管理员的公关,我怀疑其他解决方案是否也不利于对其项目的积极贡献

感谢您说@nikolasleblanc

看着@filipesilva对#8284的响应,我已经意识到Angular CLI不适用于TypeScript中的库。

@filipesilva ,感谢您解释此问题并提供解决方法。 另外,我想更详细地解释我的情况。

我们的团队面临与@rolaveric相同的问题。 我们正在构建一个产品套件,该套件由针对不同领域的较小应用程序组成。 由于所有应用程序均遵循相同的设计准则,因此我们拥有一个包含可重复使用的共享组件的库。

实际上,我们没有专门的图书馆开发团队。 它仅用作可重用代码的容器,可从应用程序中引用该代码。 因此,我们的库不是一个独立的项目,仅在应用程序内才有意义。

我们的团队将TypeScript视为第一手编程语言。 这意味着所有开发都在TypeScript中进行,并且所有存储库都使用相同的TypeScript版本和配置。 考虑到这一点,我们决定仅使用TypeScript来发布共享库,以避免额外的复杂性。

我了解我们这样做的后果自负,并违反了Angular软件包格式。 但是,由于Angular CLI目前没有为库提供解决方案,因此该方法有助于避免为库配置和维护自定义生成过程的额外复杂性。 此外,这使我们可以直接从应用程序直接引用和测试库,从而大大简化了应用程序开发过程,从而获得了出色的Angular CLI功能(例如实时重新加载)的所有优势。

我承认这听起来似乎有些棘手,但从另一方面讲,它可以帮助团队专注于产品开发,而不是Angular构建过程。

当前,我们考虑使用Angular

有人面对同样的问题吗? 您会针对这种情况建议哪种方法?

  • 使用自定义构建过程(例如ng-packagr
  • 将单存储库与Angular
  • 交付TypeScript库并等待Angular团队的正式解决方案
  • 还有别的

@alexeikostevich如果您处于封闭的公司环境中,甚至可能拥有自己的私人npm注册表,那么我会说

  • 交付TypeScript库并等待Angular团队的正式解决方案

很好。 去年我们一直在这样做,这对我们目前造成的麻烦最少。 不将TS发布到公共npm注册表是关于Web标准(ECMAScript是一种标准,不是TypeScript),互操作性和易用性(并非每个人都希望设置翻译器)。 如果TypeScript是公司内部的事实上的标准,那么没有什么可以阻止您在内部发布TypeScript软件包。 如果它对您有用,那就去做。

Nrwl / nx通常从角度应用程序开发的角度描述一个重要的故事(monorepos),而图书馆开发解决方案。 例如,我对Nrwl / nx不满意的是libs是作用域包,但是作用域名称是从工作空间的名称派生的。 因此,您不能在同一工作空间中开发具有不同包作用域的包。 既然您说您的库仅在您的应用程序中有意义,那么特定于项目的npm-package范围对您来说可能不是一个大问题。 但是,如果您有一项政策,所有软件包必须共享一个公司范围内的通用软件包范围,那么我想对于多个工作区,所有这些工作区都必须命名为相同,否则您实际上只能在一个工作区和仓库中进行开发公司所有的图书馆。

除此之外,当我尝试通过npm安装Nrwl / nx时不起作用。 我不得不使用他们的bash脚本安装过程。 出于我自己的目的,在包范围内缺少灵活性是一种限制,我在此编辑中发布了一个问题但到目前为止还没有得到答案将来的版本中可能会解决这种情况

您会针对这种情况建议哪种方法?

恐怕它不是您要寻找的答案,但最终我还是建议您不要等待建议,而自己花一个小时或半天时间尝试Nrwl / nx和ng-packagr。 我相信您会很快发现自己是否满足您的需求。

感谢您的详细回复@ about-code!

我们确实将TypeScript库发布到私有公司NPM,因为该软件包不符合Web标准,但是它有助于我们继续进行产品开发并保持高效。

正如您所建议的,我们一定会在不久的将来审查当前可用的替代方案。 看来我们步履蹒跚,用TypeScript交付了库,这可能阻止我们将来更新到Angular / Angular CLI。

我想提出这个问题,因为这种用例对于企业开发而言应该是非常典型的。

只是想知道构建只为基于CLI的应用程序生成库的东西会更容易吗?

如上所述,用于构建在CLI中使用的库的

https://github.com/dherges/ng-packagr (实现完整的Angular包格式)
https://github.com/fintechneo/ngmakelib (最小解决方案,不是完整的Angular软件包格式,但是至少可以在其他CLI应用程序,ngc / rollup和SystemJS中使用,我是本文的作者)

@neo尽管其构建过程没有直接利用CLI,但是我的库Angular Librarian编译为Angular软件包格式

大家好
上面提到的诸如ng-packagr之类的工具确实使我深受启发。
我建立了一个简单的库示例,该示例基于基本的angular-cli应用程序和ng-packagr。 它内部具有预览应用程序,支持演示/开发人员模式,并且可以轻松导入到正在运行的angular5应用程序中。 我还添加了compodoc和live-rebuild模式,使其更酷。

在这里查看: https :
阅读文档(预先抱歉,我不太擅长编写漂亮的文档),可以随时在本地package.json文件中重命名lib,并用您自己的前缀替换所有'yo-'前缀。

@alexeikostevich

看来我们步履蹒跚,用TypeScript交付了库,这可能阻止我们将来更新到Angular / Angular CLI。

实际上,我对此不太担心。 就向后兼容性而言,TS相当稳定。 您唯一需要确定的是,您的库不会将TypeScript声明为硬(dev-)依赖项,而是将其声明为对等依赖项,其版本范围以lib期望的最小TS版本开头(基于它的语言功能)使用)直到下一个主要版本。 如果Angular需要TypeScript的较新版本,则您的库的使用者可以选择安装CLI所需的较新版本或最新的TS版本,并继续使用和编译您的库。

@ about-code是否可以在“ Typescript库”中使用angular / cli?
如果我正确理解,则可以使用专用的Typescript软件包,
您介意分享如何设置它们吗? 谢谢你的时间!

@matheo我只定期使用@ngtools/webpack ,所以不能谈论CLI。 但是从我的理解上来说,TS库只是带有TS源而不是JS源的普通旧NPM软件包。 他们发布到内部NPM注册表untranspiled和时使用GET安装到相关的node_modules。 他们应该具有与index.ts相同级别的package.json 。 TS实现节点解析算法,并且在通过import { FooClass } from "package-name"导入索引文件时可以找到索引文件。 索引文件应(重新)导出lib的公共API-并且仅导出公共API。 尝试避免像export * from "..."这样的再出口。 在TS应用程序中使用时,TS库会与它们所使用的应用程序一起进行编译。

我再次强调,TS库应仅存在于私有注册表和软件包中。 NPM和节点生态系统不应被TS库污染,因为它们不是JavaScript且非标准。 还要注意@alexeikostevich写了什么,以及他链接的问题。 一些Angular-CLI贡献者强烈反对TS-lib(请参阅https://github.com/angular/angular-cli/issues/8284#issuecomment-341417325),所以不要认为我的观点是理所当然的。

@ about-code我们应该一起建立一个注册表吗?😅那也是我的想法

@ about-code我想出了一种用ng-packagr编译我的库的方法,但是没有在回购目录的根目录下,而是在一个子文件夹中设置CLI项目。 然后,我将库编译为/dist ,并从根目录package.json引用它,以供其他项目使用。 在完成所有工作后,我将分享有关此设置的更多信息。
感谢大家所做的出色工作! :感恩

在我上一期评论之后...

我已经做了很多工作,在分析了我的工作之后,我认为我们可以将问题分为三个部分,其中只有1(数字3)是与angular相关的问题

  1. 项目管理(文件结构和设置)
  2. 包装/捆绑
  3. 编译中

我将在(1)和(2)上简要地写一下,(3)是需要立即解决的事情。

请注意,(1)和(2)并不是angular唯一的,任何框架,库或原始项目都必须解决这些问题。

首先要点:

  • @ngtools/webpack与该过程无关,它捆绑了应用程序。 对于库编译,我们需要使用@angular/compiler-cli
  • Webpack只能用于编译资源(不驱动进程也不捆绑)。 对于开发环境,这将产生相似的结果,并允许使用我们已经拥有的加载器配置!

项目管理

Angular CLI已经这样做了,但是针对应用程序而非库。
图书馆需要一个用于集成测试和轻松开发的演示应用程序...这意味着任何项目都是单仓库...
这并非易事,正确的设置需要对打字稿和Webpack进行高级配置。

目前, Nx工作区提供了适当的解决方案。

包装/捆绑

这是获取编译输出(JS)并将其打包为一种或多种格式的过程。
Angular对此有一个规范,可以在FESM ES2015,FESM ES5和UMD中创建捆绑包以及d.ts文件和metadata.json文件。
这是非常技术性的,并且已经在几个项目( material2ng-packagerangular-library-starter )中正确完成了

这是一个外部过程,可以在cli中或通过其他软件包通过@angular/dev-kit通过单独的配置文件来完成。 由于存在解决方案,我们现在可以使用它们。 它纯粹是一个实现,绝对不是问题。

编译中

以下是冗长而复杂的道歉:)

编译是将TS文件提取为JS文件。 使用TypeScript( tsc )相当简单,但是使用角度编译器( ngc )变得很复杂
痛点是资源(html,scss等):

  • 角度编译器只知道如何处理HTML和CSS,其他格式(SCSS,LESS)将不起作用。
  • 编译器不会内联库所需的资源。
  • 资源出现在两个位置,分别是JS输出和AOT编译器发出的meta.json文件。

ng-packager使用外部过程和后处理脚本解决了这个问题,这意味着使用与开发环境不同的工具(开发人员使用webpack,后处理使用gulp工具)并在外部而不是编译器的一部分进行操作。

@angular/compiler-cli包是可扩展的,可以考虑如何加载资源,以便在编译过程中加载资源(无需后处理,本机内联)。 问题在于它缺少通过webpack加载资源所需的异步API(请参阅angular / angular#20130)
修复此问题后,它应该很容易做到(可以通过在本地创建API知道这一点,所有要求都可以使用)

通过创建CompilerHost并将其传递给angular,我们可以控制资源加载,编译器主机是资源的加载器(除其他外)。
现在,我们需要的是一种使用webpack在编译器主机内编译ngc 。 我们还添加了自定义转换器来动态内联所有资源,仅此而已!!!

为此,我们需要在CLI中有一个API,可以为我们(在运行时)创建webpack配置并停止(而不是构建应用程序),然后可以创建webpack实例并创建可以编译资源的编译。

它可能看起来很复杂,但是我已经有一个可以正常工作的POC,它将一个补丁应用到cli上,该cli允许提取配置,然后从那里运行通过Webpack加载本机资源的编译。 结果经过汇总并创建捆绑包。

完成编译步骤时,无需额外的逻辑或复杂的cli。

@filipesilva @hansl如果有可能,我们可以讨论一下,我将提出一个建议,该建议只允许集成编译步骤(不捆绑,不汇总,什么也不做)。
这是第一步,它将打破编译障碍,允许ngc输出具有通过cli配置通过webpack内联和编译的资源。

这是一个逻辑流程:

  • 调用CLI API以获取用于构建状态(构建,生产,开发等...)的webpack配置对象
  • 使用已加载了webpack资源加载器并准备通过加载器链编译资源的自定义编译器主机。
  • 使用编译器主机和内联转换器调用performCompilation (异步版本)。
  • 输出准备好捆绑

好吧,有了PR#8643,我们应该能够取得良好的进步。

@shlomiassaf是的,它涉及作为同步API的TypeScript转换。 因此,从那里开始,我选择对*.ts源进行两次传递。

https://github.com/dherges/ng-packagr/commit/4753066ba7a75e6d570d0ce45052252a56b97214

dherges / ng-packagr#279

它不是真正的打字稿转换,而是更多的角度编译器实现。

编译器cli在内部将其分为2遍,从而绕过了TS的同步限制。
因此,第一遍将加载所有资源。

ngc -p不会执行异步操作,因此取决于用户这样做...

我创建的PR(#8643)应该可以解决此问题

只是想在这里添加一些评论。

在我当前的项目中,我们有一个多应用程序的cli cli应用程序,该应用程序由5个应用程序和1个components文件夹组成,它们共享应用程序之间的所有通用组件。

以前,我们很少使用带有已安装组件文件夹的docker容器来开发所有应用程序,并在开发过程中立即查看更改。

一段时间后,我们决定将源移动到一个单一的多应用程序中(这样会更加灵活)。 但是我们遇到了一个问题,所有配置文件和所有应用程序都必须在同一文件夹内,即我们必须在同一个文件夹中有10个配置文件(1个用于应用程序,一个用于规格),并且必须包含该应用程序的每个配置文件从编译中排除所有其他应用程序。 我们发现,不友好的原因导致cli限制了我们,并且也没有机会使用其他基础结构。 确切地说,具有aot的ngc不支持任何baseUrl配置(相对路径等)。

Angular Package Format是一种非常不错的方法,但是对于开发而言,它会带来很多麻烦,因为每次更改软件包时都必须编译并安装软件包。

@ serhiisol我有一个10apps的monorepo。 您不再需要排除所有其他应用。 在以前的CLI版本中已解决此问题。 您可以在tsconfig.app.json中使用以下内容:

"include": [ "app1/**/*", "shared/**/*" ], "exclude":[ "**/*.spec.ts" ]

可能是这样,但是您不能将配置文件保留在应用程序源本身中,它们也与所有其他源文件保持同一级别(例如10apps * 2配置文件= 20 tsconfig文件,这很奇怪)。 除此之外,如果将配置文件移动到应用程序源文件夹中,则将没有组件文件夹(包含所有组件,这些组件在应用程序之间共享),而aot将不起作用:)

@dherges在这种情况下,AOT编译对您

ERROR in ./apps/calculator/src/main.ts
Module not found: Error: Can't resolve './../../../$$_gendir/apps/calculator/src/app/app.module.ngfactory' in '/Users/serhii.sol/Development/mono-app/apps/calculator/src'
resolve './../../../$$_gendir/apps/calculator/src/app/app.module.ngfactory' in '/Users/serhii.sol/Development/mono-app/apps/calculator/src'
  using description file: /Users/serhii.sol/Development/mono-app/package.json (relative path: ./apps/calculator/src)

PS。 似乎这种方法不适用于惰性路由(loadChildren)

@serhiisol有一些方法可以使自动加载和延迟加载正常工作(使用在我创建的https://github.com/nekkon/angular-cli-library仓库中的变通方法),但是我同意这不是正确的方法或具有20tsconfig文件。 我认为所有这一切要等到Angular团队给出最终正确的解决方案/方法后,才能解决如何通过共享的组件库使多个应用程序成为单一仓库的情况(如果发生这种情况,取决于它的重要性)。 我还没有检查https://github.com/nrwl/nx ,这可能是一个很好的解决方案。

最新状态是什么? 是否有用于打包库的文档? 这是一个很长的线程。

查看此演讲: Juri Strumpflohner-创建和发布像Pro一样的Angular库@ juristr

它涵盖了使用汇总工具和其他一些工具的大多数文档。

所以基本上...
自最初的建议发布以来已有一年半的时间,但对于组件框架的基本能力而言,仍然没有官方的解决方案。 👎

NgPackagr是支持Angular Library开发的出色工具

NgPackagr是支持Angular Library开发的出色工具

没有webpack支持,因此没有require.context ,webpack加载程序和所有这些东西

@artaommahe Webpack不适合用于库构建,这是一个已知问题:

但是由于Webpack仍在发展,这种情况将来可能会改变。

@artaommahe Webpack不适合用于库构建,这是一个已知问题:

与无法将图片/ svgs内嵌到lib bundle相比,非最优的bundle大小和内容对我们来说是一个较小的问题)

有时我只是觉得也许我们应该只使用git子模块

好的,据我所知,有多种包装工具/策略,或者至少是入门者,但我仍然缺少一件事。 如果我在使用该库的应用程序中无法立即看到更改,该如何实际开发这些库?

我有一个应用程序,它使用5个不同的库。 一个人很直截了当,可以在没有在应用程序内对其进行测试的情况下以良好的测试覆盖率进行开发,但是其他人则相当复杂,并且依赖于这5个库中的几个库,因此如果没有在应用程序中将它们链接/一起使用,我看不到一种方法发展他们? 在Angular 5之前,我可以将所有这些项目一起npm link (它们只是普通的git仓库项目,基本上是由ng new生成的应用程序),并且一切都可以正常工作。 但是由于Angular 5,如果他们不遵循APF,我将无法再在Angular 5应用程序中进行npm link项目。

我可以使用此线程中列出的一些工具来开发构建过程,mono repo,以及生成与APF兼容的库所需的任何东西,但是我该如何开发它们呢? 我看到支持我的案例的唯一方法是开发一个流程,该流程将在每次更改时将项目构建到APF兼容的lib中,并将所有链接链接到一个应用程序中。 但是我不确定这将有多快,而且一开始要花一些时间来开发它,所以我对这种方法不是很感兴趣。 这真的是唯一的方法,还是我错过了什么?

@metodribic有你看着由@vsavkin和团队提供的解决方案在Nrwl -我认为这已在此线程之前被提及。

我们目前正在将其用于具有9个内部库的大型企业应用程序,并与15个开发人员团队一起运行大约4000多个测试。 如果您有兴趣,我很乐意讨论我们的工作流程和工具-不幸的是,我无法共享我们的代码。

@mattem我很感兴趣,如果您愿意,请加我:)

也出现了新的JavaScript工具,可以提供
完美替代基于Java的编排系统(例如buck,
bazel等)。 https://github.com/boltpkg/bolt要考虑的问题:-D

在星期一,2018年1月22日在11:11刁Tibaquirá [email protected]
写道:

@mattem https://github.com/mattem我很感兴趣,如果有的话,加我
请 :)

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件,在GitHub上查看
https://github.com/angular/angular-cli/issues/6510#issuecomment-359531953
或使线程静音
https://github.com/notifications/unsubscribe-auth/ADQBMIlpYx5RbvPrQoL0l52iDED98rLAks5tNN16gaJpZM4Nqsq5

@mattem我也想知道您与nx的设置和工作流程,非常需要它

@TheLarkInn在ng Europe见!

@matheo @avatsaev我将尝试写一些有关我们所拥有的工作流程及其工具的内容

@mattem也有兴趣! 我们将尽快迁移到此工作流程。

我很乐意看到像@ angular / cli / Nrwl这样的项目与类似于bolt这样的项目一起解决以通用方式解决库管理问题:)

@matheo @avatsaev @jogelin我们已经在我们的应用程序中运行了大约4个月的nx工作区。 我们有11个库,并且开发经验还不错(即不妥协)。

我们尚未将这些库中的任何一个库重新制作成自己的repro或发布到我们的内部npm注册表中,但是到目前为止还不错。

@mattem我也会对您的撰写感兴趣。

@kevinkuszyk通过CI获取库并将它们发布到私有npm reg实际上是最棘手的部分,这是我感兴趣的部分。

@metodribic

但是由于Angular 5,如果它们未遵循APF,我将无法再在Angular 5应用程序中链接项目。

您必须在.angular-cli.json配置中添加保存符号链接

...
"defaults": {
    "styleExt": "scss",
    "component": {},
    "build": {
      "preserveSymlinks": true
    }
  }
...

@avatsaev太奇怪了,我只是检查了nx文档,却没有提到将libs发行到自己的repro或单独发布中。 这是我们选择nx时使用的两个标准。

@vsavkin我是否正确记得,还是有变化?

我们讨论了有关前端框架使用什么的讨论,并且在阅读了Hero教程之后,我非常喜欢Angular的设置方式以及构建模块的简便性。

我想将我们的服务和模型与组件分开,以便其他项目可以重复使用这些服务。 但是,现在我发现Angular并不是为了拥有外部库而构建的,除非您要从人们编写的20种技巧中选择一种。 那是对公司的艰难出售。

有趣的是,在这些前端框架的所有优缺点中,Angular旁边没有巨大的星号。 肯定有。 这应该是Angular的优先事项#1,但是在看到这个问题已经解决了一年半之后,事实并非如此,这确实是个大问题。

@Holzberg有一些我不会考虑使用hack的解决方案,并且允许您创建库:

而且,是的,还有其他方法可以使angular-cli达到目的。

而且,如果您想为库提供Angular Mono仓库,可以看看
在此: https :

2018年1月23日,星期二,21:29,Matt Fehskens [email protected]
写道:

@Holzberg https://github.com/holzberg我有一些解决方案
不会考虑黑客行为,而是允许您创建库:

而且,是的,还有其他方法可以使angular-cli达到目的。

-
您收到此消息是因为您已订阅此线程。
直接回复此电子邮件,在GitHub上查看
https://github.com/angular/angular-cli/issues/6510#issuecomment-359919986
或使线程静音
https://github.com/notifications/unsubscribe-auth/AQv-Wmx8nPPZSbNeJZZ7H4_v96A9ZbjAks5tNkEigaJpZM4Nqsq5

@gonzofish这些库都是第三方的。 没有标准方法。

我尝试了ng-packagr,并在将库安装到客户端应用程序后就可以编译并正常工作了,但是如何简化开发呢? 我可以将文件链接到演示Angular应用程序以便测试吗? 糟透了,我每次都要编译。 我删除了主要的应用程序组件,因为这不是必需的,并且我不想仅保留它来进行测试。

我唯一想到的另一种方法是在规范文件中创建测试,但这不允许我查看指令的渲染结果。

我尝试了ng-packagr,并在将库安装到客户端应用程序后就可以编译并正常工作了,但是如何简化开发呢?

同样的问题。 无法通过yarn link在源代码上轻松开发,因为链接文件不是由主应用程序的webpack编译的

关于在本地使用ng-packagr ,只需将引用添加到主package.json中的/dist文件中,便可以yarn link您的库,例如:

  "main": "dist/bundles/coachcare-datepicker.umd.js",
  "module": "dist/esm5/coachcare-datepicker.js",
  "es2015": "dist/esm2015/coachcare-datepicker.js",
  "typings": "dist/coachcare-datepicker.d.ts",
  "metadata": "dist/coachcare-datepicker.metadata.json",

您可以在dist/package.json找到相应的文件

@matheo如何链接未编译的文件? 我相信这就是@artaommahe所引用的内容。

我有同样的问题。我可以很好地链接我的dist,但是每次更改都需要生成完整的汇总版本,这会加快开发速度

今晚在山景城的Angular聚会上有一个关于包装库的演讲。 我希望我们将展示新的ng_package bazel规则,我们正在将Angular本身用于包装框架,该规则也将适用于第三方库。

@alexeagle可以稍后在网上某个地方进行此演讲吗?

我相信这次聚会的演讲会被记录下来,是的

@dherges在ng-packagr中,如何包含外部库? 例如,我想使用crypto-js并通过npm安装它,但是使用我的库的项目出错了。 我也尝试安装@type/crypto-js ,但是也没有用。

我想念什么?

只需将我的https://github.com/dominique-mueller/angular-package-builder放在这里,这也可以完成工作。 尽管如此,我还是更喜欢这种“官方”解决方案...

@Holzberg您能否更具体地说明“错误出局”的含义? (最好在此对话中打开一个问题:))

@alexeagle您知道是否会很快发布有关事件的录像: https : //www.meetup.com/it-IT/Angular-MTV/events/246637957/

@meriturva视频在这里: https : //youtu.be/QfvwQEJVOig?t=1h12s

还等待“正式”过程。 同时,通过git子模块对角项目进行子调制是有效的。

当前有一个WIP,将来可能会将ng-packagr (https://github.com/angular/devkit/pull/444)包括在内作为Angular CLI的构建工具。

同时,使用ng-packagr完全可以,或者您可以使用nrwl / nx Angular CLI扩展提倡的更多“ monorepo”设置。 我最近谈论过这些,演讲视频也应该很快播出:

  • 回购: https :
  • 幻灯片: https
  • @eggheadio视频: https//t.co/e9dogjKKlg

特定的存储库具有分支,这些分支显示了各种设置可能性。

@juristr上传后,请在此处发布视频,非常需要,谢谢:)

因此,对于每个感兴趣的人,我在ngVikings的演讲都结束了:

我也想分享一些我想出的东西,以便为整个问题提供最终的解决方案。 也许听起来有些琐碎,但对某些人还是有帮助的。

@juristr的仓库可以创建一个库,但是还需要有一个库的演示,对吗? 因此,想法是该回购协议具有/用途:

  • 所有角度/ cli功能
  • ng-packagr以构建库

我们可以用angular cli应用程序是一个演示应用程序来扩展它,在开发过程中人们可以开发并查看结果,最重要的是向用户展示库的实际操作。

关键配置点是(当然,以下所有内容都不严格):

  1. 将angular cli的输出更改为dist-demo
  2. 将ng-packagr输出文件夹更改为dist-lib
  3. 将存储库名称添加为package.json构建的基本URL: ng build --prod --base-href=/<your-repo-name-here>/
  4. 修改.gitignore以包括上面的dist文件夹

最后配置travis,将演示程序既部署到github页面,又将库部署到npm repo,类似于:

language: node_js

node_js:
  - '8'

script:
  - npm run build
  - cp dist-demo/index.html dist-demo/404.html
  - npm run packagr

before_deploy:
  - cd dist-lib

deploy:
  - provider: npm
    email: <your-email-here>
    api_key: $NPM_TOKEN
    skip_cleanup: true
    on:
      tags: true
  - provider: pages
    local-dir: dist-demo
    skip-cleanup: true
    github-token: $GITHUB_TOKEN
    keep-history: true
    on:
      branch: master

在这里,您可以轻松完成demo

如果将来的angular / cli也可以为该库生成travis配置,那将是相当不错的,因为根据我的经验,travis并不那么适合新手。

ng-packagr面临的唯一问题是,它会预先编译所有内容,因此无法为特定项目添加特定样式或覆盖SCSS变量。

要像angular-material做,有必要删除视图封装,这将是对组件/ scss的巨大重构。

我不认为这种情况是否有解决方案solution

使用CSS变量;-)

不幸的是, @oliverjanik ,在某些情况下,我们需要支持不支持CSS变量的浏览器,例如IE 11(企业应用程序)😞

scss /任何样式变量配置的不可能不是来自ng-packagr 。 这是AoT的局限性,它需要事先编译所有内容。 因此,Angular CLI可以/应该解决的也不是问题。

这个问题的唯一可见(对我而言)的解决方法是,在角铁芯侧的ViewEncapsulation之上的另一种解决方法,该方法可以支持来自角铁的样式变量(从金色成分变量到样式注入)。 实际上,angular不仅需要将数据绑定到HTML,还需要将数据绑定到CSS。

从有角度的内核的角度来看所有这些,我宁愿在主要浏览器中等待CSS变量,什么也不做,而不是构建一个可预测的死机框架。

因此,请扩展@oliverjanik所说的内容,使用CSS变量,或者等到主要浏览器支持它们为止:)现在,不要使用组件样式。

我刚刚阅读了几个小时前对angular CLI的更新,看起来我们终于可以使用此功能了:+1:

图书馆支持! 这是最需要的功能之一。 您可以使用ng generate library <name>在项目中生成一个新库。

@geocine关于如何安装此程序的任何提示? 我刚刚安装了最新的cli,但看起来还不可用。

更新:我在6.0.0 rc2(https://github.com/angular/angular-cli/releases)中看到了它,但是它似乎还没有运行。

@ivanirjoao库功能仍处于候选发布形式; 尚未完全发布。 因此, yarn add @angular/cli@latest仍然会给您1.7.4yarn add @angular/cli@next应该会给您发行候选。

查看所有可用版本: https :

你好!

只能使用ng generate library命令创建一个新库吗? 并在创建_application_项目之前。

我认为以这种方式(除了_generate_之外)创建一个新的Lib项目会很方便:
ng new <name> --type library

ng new <name> --type library +1,如@aastrouski建议

在Angular CLI的6.0.0版本中,您将能够创建,测试和处理lint库。

此功能在最新的6.0.0 RC中可用,可以在https://github.com/angular/angular-cli/blob/master/docs/documentation/stories/create-library.md中临时找到文档

它支持子库吗?

例如@ angular / common / http或@ angular / core / testing

谢谢。

2018年5月3日,星期四,2:22 Filipe Silva [email protected]写道:

在Angular CLI版本6.0.0中,您将能够创建,测试和运行
库。

最新的RC 6.0.0版本中提供了此功能,并且
可以在以下位置临时找到文档
https://github.com/angular/angular-cli/blob/master/docs/documentation/stories/create-library.md。
当6.0.0最终版本完成后,文档将移至主Wiki。

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件,在GitHub上查看
https://github.com/angular/angular-cli/issues/6510#issuecomment-386150875
或使线程静音
https://github.com/notifications/unsubscribe-auth/AFIN3XLCMpv9hR04NamAEKAfwSLjFZwiks5tuj-ZgaJpZM4Nqsq5

它支持子库吗?

答:是的,通过使用NX以及对ng-packer json文件和tsconfig文件的一些更改。

您可以创建子库,而无需NX 。 您可以通过配置辅助入口点https://github.com/dherges/ng-packagr#secondary -entry-points来实现

@ alan-agius4是的,这就是NX所做的,但是它还添加了自动tsconfig支持和无缝运行时支持(无需重建,演示可以在ts文件上运行)

我知道CLI会在设计上阻止此操作,但我不能那样做。
无论如何,我在构建的程序包上运行测试

由于不活动,此问题已自动锁定。
如果您遇到类似或相关的问题,请提出新的问题。

阅读有关我们的自动对话锁定策略的更多信息。

_此动作已由漫游器自动执行。_

此页面是否有帮助?
0 / 5 - 0 等级