"这不是运行时特性"复选框的意思是"这比namespace已经拥有的运行时特性不更多了吗？"

这难道不比命名空间更像是一个运行时特性吗？
精彩的问题。

正确

如果我理解这个建议的话，我们确实有责任自己为这个项目添加TypeScript。
在 TypeScript/Gulpfile.js 文件的第157行到第161行：

const createTypescriptDts = () => src("built/local/typescriptServices.d.ts")
    .pipe(newer("built/local/typescript.d.ts"))
    .pipe(append("
export = ts;"))
    .pipe(rename("typescript.d.ts"))
    .pipe(dest("built/local"));

在 TypeScript/src/services/exportAsModule.ts 文件的第1行到第7行：

// 这里我们将TypeScript服务作为外部模块暴露出来，以便像节点模块一样轻松地消费它。
// @ts-ignore
/* @internal */ declare const module: { exports: {} };
if (typeof module !== "undefined" && module.exports) {
    module.exports = ts;
}

这些天我们一直在努力迁移到外部模块，但这是一个漫长的过程。

@DanielRosenwasser 感谢分享，这很有趣。让每个人都有创建复合编译的选项，使用esnext从你的命名空间代码中创建模块，并像你上面展示的那样将模块暴露出来以便在命名空间项目中使用它们，这是否合理？似乎只需要几行代码就可以将其输出到已经存在的编译中来解决所有这些问题。
一个编译指令，如//@ts-insert,可以在不处理的情况下发出以下行，它本身就可以作为解决这个问题的临时措施。