我无法理解RxJS 中的Finalize运算符。让我用一个例子来演示这一点：

of(null).pipe(
  tap({ complete: () => console.log('tap 1 completes') }),
  finalize(() => console.log('finalize')),
  tap({ complete: () => console.log('tap 2 completes') })
).subscribe({ complete: () => console.log('subscribe completes') });

我希望finalize回调在第二个之前执行tap。但这并没有发生。相反，上面的代码会产生以下输出：

tap 1 completes
tap 2 completes
subscribe completes
finalize

看看实现，我相信操作符通过整个可观察链传递（提升），以便始终在其末端应用。所以现在我有两个问题：

1. 这个设计决策背后的理由是什么？您能否解释一下为什么这是一个理想/有利的财产？
2. 是否有不同的运算符或其他解决方案来在完成和出错时执行代码，但按顺序（即在上面示例中的第二个之前tap）而不是在可观察链的末尾？

是否可以编写一个 TypeScript 类型保护来检查给定对象是否为空？

我可以做相反的事情，即编写一个类型保护来检查对象是否为非空（此处使用 lodash isEmpty）：

isNonEmpty<T>(object: T | {}): object is T {
    return !_.isEmpty(object);
}

writeTextIfAny(param: { text: string } | {}): void {
    if (isNonEmpty(param)) {
        console.log(param.text);
    }
}

然而，当我试图扭转局面时，出现了问题：

isEmpty<T>(object: T | {}): object is {} {
    return _.isEmpty(object);
}

writeTextIfAny(param: { text: string } | {}): void {
    if (!this.isEmpty(param)) {
        // param is never, not { text: string }
    }
}

这是为什么？

我正在尝试使用Webpack为TypeScript设置构建过程。在大多数情况下，一切正常。但是我无法使源映射在Karma测试运行程序中正常工作。

问题描述

假设我有一个打字稿文件test.spec.ts（1）。该文件由TypeScript使用内联源映射（2）转换为某些ES5源。最后，Webpack 4使用eval-source-maps（3）将ES5源捆绑在一起，并由Karma测试运行者提供给Chrome。

通过检查Chrome中的Karma Debug Runner中的源代码，我可以看到所有三个阶段的转换实际上都可用于浏览器：

• （1）被映射为 webpack://test.spec.ts?c161
• （2）被映射为 webpack-internal://test.spec.ts
• （3）可作为 localhost:9876/base/test.spec.ts

在Chrome控制台中，我还获得了测试执行过程中引发的所有错误的正确堆栈跟踪。如我所料，这些包括源映射到（1）的行号。例如：

Error: Oh no!
    at Function.MyClass.myBadMethod (test.spec.ts?c161:9)
    at UserContext.eval (test.spec.ts?c161:21)
    at <Jasmine>

但是，因果报应本身会记录仅行映射到（2）的行号错误。例如：

Error: Oh no!
    at Function.MyClass.myBadMethod (webpack-internal:///./src/test.spec.ts:8:15)
    at UserContext.eval (webpack-internal:///./src/test.spec.ts:17:17)
    at <Jasmine>

这是完全无济于事的，因为（2）只是一些中间源，甚至从未写入磁盘。实际上，我不需要（2）的源映射，也不了解为什么首先将它们包括在内。如果可能的话，我想尝试禁用它们（当然要为（1）保留正确的源映射）。

无论如何，重要的是要让Karma报告具有相对于原始文件的行号的堆栈跟踪，就像在Chrome控制台中一样。如有必要，我也愿意为此付出执行速度

如果您想不出一个完善的解决方案，但对TypeScript / TS-Loader / Webpack / Karma-Webpack / Karma有一些见解：我也对有助于查明该工具链中问题的任何论据感兴趣。

最小的测试配置

devDependencies来自 package.json

"devDependencies": {
    "@types/jasmine": "~2.8.7",
    "jasmine": "~3.1.0",
    "karma": "~2.0.2",
    "karma-chrome-launcher": "~2.2.0",
    "karma-jasmine": "~1.1.2",
    "karma-webpack": "~3.0.0",
    "ts-loader": "~4.3.0",
    "typescript": "~2.8.3",
    "webpack": "~4.8.3"
}

karma.conf.js

module.exports = function(config) …