这个问题是否与generateDeepReexports编译器选项有关，或者已经通过该选项解决？
https://github.com/angular/angular/blame/master/packages/compiler-cli/src/ngtsc/core/api/src/public_options.ts#L264-L293

@petebacondarwin 这个选项似乎没有任何区别。在OP中的例子仓库里，如果我打开或关闭generateDeepExports,ng-packagr仍然会产生相同的错误，我们的内部管道仍然产生相同的输出。
generateDeepExports的文档也让我觉得它可能不太合适：当包被构建时，正在导入的本地依赖项不在APF中，但它将在下游项目中作为依赖项安装时成为APF。

我查看了一下仓库，我认为这里的根本原因是 OneModule 是从源代码中消耗的，这使得 OneModule.forRoot 的实现暴露给了 Angular 的静态解释器(而不是仅仅暴露 .d.ts 文件)。当根据 .d.ts 元数据解释函数调用时，编译器使用一个 "foreign function resolver" 来提取一个可以评估的表达式：
angular/packages/compiler-cli/src/ngtsc/partial_evaluator/src/interpreter.ts
第 457 行到第 477 行
| letexpr: ts.Expression |null=null; |
| if(context.foreignFunctionResolver){ |
| expr=context.foreignFunctionResolver(lhs,node.arguments); |
| } |
| if(expr===null){ |
| returnDynamicValue.fromDynamicInput( |
| node,DynamicValue.fromExternalReference(node.expression,lhs)); |
| } |
| |
| // 如果外部表达式出现在不同的文件中，那么假设调用表达式的拥有者模块也应该用于解析外部表达式。 |
| if(expr.getSourceFile()!==node.expression.getSourceFile()&& |
| lhs.bestGuessOwningModule!==null){ |
| context={ |
| ...context, |
| absoluteModuleName: lhs.bestGuessOwningModule.specifier, |
| resolutionContext: lhs.bestGuessOwningModule.resolutionContext, |
| }; |
| } |
| |
| returnthis.visitFfrExpression(expr,context); |
重要的是，如果函数是通过绝对模块规范符导入的，它会努力切换评估上下文以开始跟踪原始导入规范符。对于具有主体的函数，编译器无论如何都会使用当前的评估上下文：
angular/packages/compiler-cli/src/ngtsc/partial_evaluator/src/interpreter.ts
第 480 行到第 497 行
| letres: ResolvedValue=this.visitFunctionBody(node,fn,context); |
| |
| // 如果尝试解析函数体的结果是一个 DynamicValue,尝试使用如果存在的话。这仍然可能产生一个可用的值。 |
| if(resinstanceofDynamicValue&&context.foreignFunctionResolver!==undefined){ |
| constffrExpr=context.foreignFunctionResolver(lhs,node.arguments); |
| if(ffrExpr!==null){ |
| // 这个函数能够从这个函数中提取一个表达式。看看那个表达式是否会导致非动态结果。 |
| constffrRes=this.visitFfrExpression(ffrExpr,context); |
| if(!(ffrResinstanceofDynamicValue)){ |
| // FFR 产生了一个实际的结果，而不是动态结果，所以用那个替代原来的解析。 |
| res=ffrRes; |
| } |
| } |
| } |
当应用与外部函数相同的技术时，如下所示，您的示例使用 @scope/one 作为模块规范符正确编译。我在评估函数体之前添加了以下逻辑：

// If the function occurs in a different file, then assume that the owning module
    // of the call expression should also be used for evaluating the function body.
    if (fn.node.getSourceFile() !== node.expression.getSourceFile() && lhs.bestGuessOwningModule !== null) {
      context = {
        ...context,
        absoluteModuleName: lhs.bestGuessOwningModule.specifier,
        resolutionContext: lhs.bestGuessOwningModule.resolutionContext,
      };
    }

这对你来说听起来合理吗？

我们一直在每隔几个月遇到这个问题，目前我们的解决方案是将 forRoot() 函数替换为另一种设置(例如第二个仅包含根模块)。我们现在开始遇到更难解决的情况。
@JoostK 你提出的修复方案是否可行，或者能否为我们添加必要的钩子来解决这个问题？
编辑：在写这条评论后，我意识到 emitCallback 确实让我们可以访问 typescript Program 上的 afterDeclarations 钩子，所以我已经能够将我们已经为 .js 文件找到的相同解决方法更新为也适用于 .d.ts 文件的方法。