Typescript: 您不喜欢 TypeScript 网站和文档的哪些方面？

“实用程序类型”页面不是最新的

新的实用程序类型经常被遗漏或未添加到手册的“实用程序类型”页面（例如Parameters<T> ）。 我经常不得不求助于浏览lib.es5.d.ts而不是手册。

标签： docs

官方 TypeScript Playground 不如开源替代品

https://typescript-play.js.org比官方做得更好：它涵盖了多个版本的 TypeScript，允许共享更大的文本，它支持所有编译器标志，并且默认情况下启用严格模式。

标签： playground

缺少发行说明的索引页

我希望有一个索引页面列出此 URL下所有过去的发行说明： https://www.typescriptlang.org/docs/handbook/release-notes 。 这样，我们就可以在 TypeScript 上跟踪过去的版本更新。

标签： docs , release notes

没有类型名称的词汇表

如果您传递了诸如const a: "foo" | "bar"类的代码，您可能不知道将其称为联合类型。

这是一个非常低的标准，但是当我们开始谈论存在/条件/映射/等类型时，能够转到一个只是尝试定义它的页面，但没有对其进行深入记录，这样您就可以获得概述，这很好该语言的所有分类法

标签： types , handbook

没有可与非技术人员共享的页面

这个我最初需要说服工程以外的人（想想 PM，非技术经理）使用 TypeScript 的价值是什么。 最后我自己写了

标签： guides

绝对 Typed 文档位于 TypeScript 文档之外并且已经过时

TypeScript 项目应该拥有相关的文档。 绝对类型的文档位于：

• https://definelytyped.org
• https://github.com/DefinitelyTyped/DefinitelyTyped#how -can-i-contribute

TS 文档可以包含它是什么的概述，为什么使用它，我们可以弃用官方网站

标签： definitely-typed

不循序渐进地教 TS

（编辑以提高可读性）我觉得文档在具有明确的“角色”时最有效。 当这些文档被创建时，ES6 还不是一个东西。 创建这些文档后，您可以在一个下午学习所有 TS。

时代变了。

我制作了react-typescript-cheatsheet bc 我觉得 TS 文档特别不适合已经知道 es6 并且也不想一次性学习高级 TS 的人。 所以专门针对有经验的 JS 开发人员第一次尝试 TS。 我们有很多人。 当前的文档要么是“嘿，这里是什么类”，要么是“在我们的类型运算符文档的同一页面上，这里有一堆看起来很吓人的泛型”。

特别是这里是一个非详尽的角色列表，可以考虑作为一个进步的老师：

• 只想将 TS 与 JSDoc 一起使用的人，没有构建步骤
• 想使用 TS 的人，尽可能不写任何泛型
• 将代码库从 JS/Flow 迁移到 TS 的人
• 不熟悉 TS 的人，采用了 TS，但第一次看到不熟悉的、冗长的错误并且不知道如何处理它的人（这是“故障排除”受众）或选择退出
• 想要发布 TS 库与 TS 应用程序的人
• 想学习使用类型运算符的人
• 想要了解可以帮助他们的类型实用程序的人
• 需要输入无类型库的人（这在很大程度上是一种网络效应，也是 TS 的兴趣，使 .d.ts 编写得尽可能简单且有据可查）
• 和aaaaaaall最后，想要学习如何编写自己的泛型类型逻辑的人
• （也许）想要编写需要遍历 TS AST 的插件的人

这些都是采用 TS 的过程中的所有阶段，我们应该将其绘制出来，并确保文档中没有一些悬崖让人们因为不知道该怎么做而因此认为这太难了。

我认为文档可以做很多事情来帮助消除以下神话：

• 您始终需要最大的类型安全性（不仅在 tsconfig 中，而且在我们在键入函数中所做的选择中）
• TS 适用于面向对象的程序员（是的，我见过这个）
• TS 只适用于 C#/Java 开发者来 JS 和错过类型，它对 JS 开发者没有真正的价值
• 您应该能够自己弄清楚如何解决 TS 错误
• 一般来说，该 TS 的入门学习曲线很高

如果资源可用，我们可以而且应该针对特定的大型开发社区来帮助他们采用，例如 React、Vue 和 Node 等。 您可以在主要文档之外执行此操作，例如 Vue 文档将Cookbook 和 Guide 区分开来，侧重于上下文中的实际示例。

这可能是后期采用 TS 的一大障碍（即需要更多文档/工具/保证/手持才能在 TS 上出售的人），正如我所能想象的那样。

标签： docs

链接的 TypeScript 语言规范已完全过时

直接在主页上您链接到“TypeScript 语言规范”。

在 GitHub 上阅读规范或将其下载为 docx 或 pdf。

但是，该规范已完全过时（停留在 1.8 版，最后一次真正更新于 2016 年 1 月），并且没有得到维护。 最好不要提及规范。

标签： spec specification outdated

代码示例的类似游乐场的小部件

在类似操场的小部件中展示文档中的所有代码示例，以及所有方便的工具提示、亮点等。

理想情况下，能够弹出一个完整的操场，编辑和查看发出的 JS/打字。

这自然会依赖于官方 TypeScript Playground 不如开源替代建议。

仅存在于发行说明中的​​ API 文档

有些类型，例如unknown ，只记录在发行说明中，这使得它们很难被发现。

标签： docs

四斜线游乐场

/tests/cases/compiler中有很多文件，加上基线就像神秘的暗物质一样。 这些兆字节可以作为文档/演示重复使用。

• 使 TS 游乐场通过以下方式从 TS 存储库加载任何文件： https :
• 让 TS 游乐场理解“fourslash”
• 向这些文件添加描述性注释

这将允许某人通过 URL 链接到有趣的语法案例，并帮助人们修补和提交其他时髦的测试。

解释给定 TS 语法的 Playground

不难发现一个非常难以理解的复杂 TS 语法。 递归泛型，通过联合和时髦的索引类型相结合……例如，这种可怕的蜈蚣的一大窝就是打字。

如果一个人能够粘贴一大块角度丰富的语法，并观察冗长的人类可消化的视图或图表，那会怎样。 要知道，在那里您无疑可以清楚地看到A是一个类，而B是一个联合类型，而C是D的泛型参数等等。

从简单的“详细 AST 漂亮打印”开始，随着时间和社区的贡献，这可以扩展到更深入的模式识别和更丰富的交互式视觉效果和类似 UML 的图表。

没有搜索文档

我经常不得不求助于谷歌搜索如何使用打字稿做某事，而不是将主要文档作为事实来源，例如使用 DocSearch 就像在 React 文档中一样

标签： search , exploration

突出社区项目

这可能是诸如聚会、社区讲座或书籍之类的事情。

但也可以使用有人可以学习的 TypeScript 的大型软件项目。

标签： Community

提供打开特定编译器标志的指南

例如，如果我打开noImplicitReturns我会遇到什么样的问题，我应该如何处理它们？ 我们在引入这些标志时随版本发行说明一起提供了这些建议，因此查找它们很棘手。

标签： tsconfig

创建编译器错误索引页

Rust 语言做到了这一点，上手需要付出很多努力（现在 TS 有超过一千个错误）但是 tsc 中的错误消息很简洁，将它们放在网站上使它们可以被搜索引擎索引，可改进并带有示例代码.

标签： compiler

如果一个人能够粘贴一大块角度丰富的语法，并观察冗长的人类可消化的视图或图表会怎样

我确实认为这会很酷，但在某些情况下，我认为对类型如何分解的高度结构化的解释（这听起来有点可能自动生成）不如识别一些常见的类型和模式组合来完成一个特定目标。 例如，假设我希望有人解释这是什么：

type X<T extends object> = {
    [K in keyof T]: T[K]
}[keyof T]

我_可以_告诉你

X是一个类型别名，带有一个类型参数T ，它被限制为object 。 当使用T实例化时，它会生成一个映射类型，其中对于K类型的每个组成部分keyof T ，该值是索引访问类型T[K] . X然后在类型keyof T映射类型上生成索引访问类型。

但它会更有帮助，但除了具有 TypeScript 工作知识的人之外，任何人都很难生产，告诉你：

X获取T成员值的类型的并集。

我认为也许拥有一组像这样的模式“食谱”可能会很方便。

Advanced Types页面只是任何非明显类型的垃圾场（我窃取了许多 TypeScript 的PHP 静态分析工具的想法，所以我发现自己经常出现在该页面上）。

那里的一堆想法是相互关联的，但这完全可以通过页面之间的超链接来完成。

Type Guard/Type Predicate 部分特别让人感觉它值得拥有自己的页面。

编写打字稿库的指南

我发现发布用 Typescript 编写的库并不是一件容易的事。 根据您的目标消费者，需要考虑很多边缘情况。 我对此有自己的看法，完全有待讨论，但为图书馆作者提供官方指导会很棒。

标签： libraries , guidance

移动导航可能很困难

我无法从手机上阅读网站手册，这很令人失望。 如果您可以在手册的每一页的页面底部有上一页/下一页导航，那也会很棒。

来自推文

标签： nav

使用更多真实世界的例子

当前的一些示例过于笼统或抽象，使用基于字母的命名约定（A、B、C）或不相关的术语（foo、bar、baz、args、obj 等）。 我希望看到更多真实世界的例子（形状、动物、产品、用户）和合法用例（API 调用、日志记录、错误处理、数据格式）。 这对于已经是抽象的概念特别有用，例如泛型和高级类型。

注意：文档的某些区域已经处理了这个问题👌🏻，但它是偶然的。

标签： examples

示例库和最佳实践

展示如何键入不同类型的函数。 像 lodash 有各种奇特的功能，比如pick、extends、flatten 等，请描述如何键入它们。

一个以递增方式构建复杂性的库。 它甚至可以阅读更多提交的链接，这些链接显示了 TS 中的某个东西是如何在生产中使用的。

无论最终构建什么，我希望有人可以很容易地添加示例。 我认为它将是像 git repo 这样的 TS 手册。

最好的开源项目通常拥有最好的文档和新的用户体验。

让我们让 TS 更加欢迎新用户。

更好地描述 tsconfig 选项

编译器选项页面上的当前描述

• 对每个选项及其如何影响编译和类型检查提供非常模糊的描述。 一些例子可能非常有用。
• 表格格式留下了一点描述空间
• 没有关于 TypeScript 版本的信息
• 字母顺序没有用，一些选项彼此密切相关，如target 、 module和lib或所有严格的选项。 当你分开看它们时，很难很好地掌握它们。 你不会明白lib不理解选项target第一。
• 大多数时候人们在 tsconfg 文件中使用这些选项，而不是tsc选项，因此当前的格式可能会让新手感到困惑。
• 一些选项的更详细描述分散在文档中，例如@types 、 typeRoots和types选项在tsconfig.json 页面和baseUrl和paths模块解析

它与提供打开特定编译器标志建议的

编辑：
更不用说与构建复合项目相关的新选项，文档中没有相关信息，您被迫根据发行说明和 GitHub 问题将整个画面放在一起。

标签： tsconfig

将文档、博客和其他官方资源收集到一个地方

如果我们能将所有关于 TypeScript 的官方资源收集到一个地方（例如www.typescriptlang.org ），那就太棒了！ 😊

例如，关于 v3.5 公告的博客文章在另一个地方（ devblogs.microsoft.com ）：
https://devblogs.microsoft.com/typescript/annoucing-typescript-3-5/

而且，v3.4 发行说明在另一个地方：
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html

我觉得这对 TypeScript 开发人员来说不是很有用，也很混乱。 😕

标签： blog , resources

通过使用您的首选项和项目设置填写 UI 表单来创建 tsconfig.json

如果文档包含一个表单/向导来帮助生成适合目标环境（浏览器、nodeJS）、用户首选项（根据用户需要严格或宽松）和项目目录结构的 tsconfig.json，那就太好了。 目前TS 编译器选项包含几个不推荐使用的选项和一些编译器标志，乍一看它们可能做几乎相同的事情（某些选项之间有什么区别，例如与路径/目录/根目录相关）。 生成的 tsconfig 应遵循 Microsoft TypeScript 核心团队的最佳实践。 其他指导性问题可能包括：

• 项目开发团队使用 TypeScript 的经验是什么（可能会向新手建议“JS 到 TS 迁移路径”相关的编译器选项，同时建议“TS 大师”的所有严格选项）
• 项目是库还是应用程序（如果库的依赖项很少，使用一些严格的功能可能会更容易，例如strictNullChecks ，因此可能会根据用户体验建议）
• 是使用 JSX/TSX (React) 的应用程序
• 您在使用使用装饰器的框架/库吗
  
  
  
  • 是否应该发出装饰器元数据，以便框架/库在运行时使用它（以框架和库为例，例如 Angular、Aurelia）
  
  

标签： tsconfig , examples , guides , wizard , exploration

@orta我认为制作

我希望网站的“手册”区域中有一个部分专门讨论对象文字以及您可以键入它们的各种方式。

例如，我经常不得不在谷歌上搜索诸如“具有任何属性的打字稿对象文字”或“具有一个必需属性和任何其他属性的打字稿对象文字”之类的内容。

而且我总是要查找{ [key: string]: any }类型，这在任何地方都没有真正讨论过。

其中一些内容在“接口”中进行了讨论，但这并不是很明显。

增加供应商类型

有时在使用绝对类型类型或其他供应商模块定义时，我发现我需要将定义调整为：

1) 覆盖/修改现有定义
2) 添加新的方法/属性

我一直无法找到有关在不同场景中完成任务的正确方法的文档。 当我需要自己做时，我也没有做好笔记🐙。 https://www.typescriptlang.org/docs/handbook/declaration-merging.html解决了第一方代码的问题，但我没有为第三方模块类型/导出提出建议。

显然，立即打开 PR 来修复/更新相应 repo 上的类型是很好的，但这可能需要一段时间才能合并回 master 分支，这可能会破坏工作流程并强制添加临时any转换和后续TODO。

标签： vendor

编译器 API 文档

wiki 有一些关于使用 Compiler API (https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API) 的信息，但只展示了如何使用它来实现某些目标的示例。 如果有更多 JSDoc 样式信息来列出存在的特定对象和方法并了解它们的作用，那就太好了。 现在我正在尝试学习 API，需要查看打字稿源以弄清楚发生了什么。

（如果因为 wiki 上提到的 API 还不稳定而没有这样做，请忽略）

标签： compiler

通过与现有语言进行比较而专注于 TS 的教程

许多人将 TypeScript 作为他们的第二（或更多）语言。 简化学习 TypeScript 的一种方法是将其与您已经知道的现有语言进行比较。 我们可以采用流行的顶级编程语言

现在我们只假设您了解 JS。

标签： tutorials

确保它默认可访问

确保像accessibilityinsights.io这样的linters通过

标签： infra

游乐场的简短、可共享的 URL

如果 TypeScript 游乐场的“共享”按钮生成短 URL，而不是将整个源代码转储到 URL 中，那就太好了。

或者，允许 URL 包含填充 Playground 的 github gist ID。 例如： https://www.typescriptlang.org/play?gist=eb25a1f350e50d6ed3561a777fbfe424

标签： playground

具有不同设置的示例（针对不同的用例/场景）

我发现很难知道如何配置我的 TS 代码库以及我可以为各种代码库遵循哪些示例，所以如果像https://github.com/microsoft/TypeScriptSamples/这样的示例列表可以在网站上显示，那就太好了展示如何配置tsconfig.json以及他/她应该如何构建 TS 文件以按预期工作。

标签： docs , examples

没有明显的原因为什么文档会出现在 wiki vs 手册中

维基中this上的

在主题和标题之间更好地导航

像手册 § 高级类型这样的大主题在单独的标题之间导航很差，也没有向上按钮。 添加浮动导航菜单会非常好。 目前很难从一个标题跳到另一个标题或快速找到想要的标题。

这是本汇编脚本 git 书中给出的一个很好的导航示例： https :

标签： website , handbook , navigation

移动友好 Playground 代码编辑

据我了解，使用语法突出显示和所有其他 IDE 功能进行移动友好的代码编辑是一种痛苦。

然而，我发现自己经常想在手机上玩代码片段，远离台式机/笔记本电脑。

我不介意一个普通的<textarea>字段，而不是一个用于移动使用的语法突出显示的编辑器。

错误可能在另一个页面或弹出窗口或其他一些 html 元素上。

标签：游乐场，手机，代码编辑器

为浏览器兼容的 es6 模块添加.js扩展的文档

没有任何地方提到 TypeScript 可以完美地生成在浏览器中工作的 es6 模块，只需在导入的名称中添加.js扩展即可！ 这个信息似乎存在的唯一地方是在这个线程中：
https://github.com/Microsoft/TypeScript/issues/16577#issuecomment -343610106

不确定是哪个版本的 TS 添加了它，但现在可以使用诸如“./file.js”之类的导入（即使文件实际上是 file.ts）。

对我来说，这是一个巨大的功能......但正式它不存在？！

高级类型页面不包括Omit<T, K>类型。

Omit<T, K>最近添加到 TypeScript 3.5 中，但是Advanced Types页面仍然有以下免责声明：

注意： Exclude 类型是此处建议的 Diff 类型的正确实现。 我们使用名称 Exclude 来避免破坏定义 Diff 的现有代码，而且我们认为该名称更好地传达了类型的语义。 我们没有包括省略type 因为它被简单地写成 Pick>.

为 Linter 提供项目设置文档

作为设置项目的一部分，包括如何使用 Linter 进行设置，很可能只是项目应该使用的 typescript-eslint。

标签： linter

没有涵盖最常见的错误或 TypeScript 限制。

当您第一次学习 TypeScript 时，TypeScript 永远不支持某些模式。 最简单的一种：

const buildResult = (name?: string) => {
  const result = {};
  if (name) {
    result.name = name; // error, this property doesn't exist on {}
  }
  return result;
};

我已经开始向我的公司介绍 TypeScript，并且像这样的案例经常出现，所以我开始以常见问题解答/故障排除指南风格记录它们。 它正在快速增长（请注意，这是一个粗略的状态）：

一次建立一个对象一个属性
为什么您在需要时没有收到错误：多余的属性检查
如何访问可选属性，包括来自联合
为什么 Object.keys 和 Object.entries 不做你想做的事
制作过滤器过滤器，使reduce工作无误
类型细化丢失

如果这些信息中的任何一个在文档中，我一直无法找到它。 我只是通过多年的反复试验和阅读 Github 上链接最多的问题才理解这些。

标签： errors , troubleshooting , limitations

提供有关如何添加自定义类型定义的清晰文档

有许多库不包含类型，并且没有可用的@types/*包。 我希望能够在我的项目中为这些文件编写我自己的声明文件，但似乎没有任何关于编写它们并让打字稿识别它们的“正确”方式的文档。 假设我正在从 npm 导入一个模块。 我需要使用declare module x吗？ 还是declare module "x" ？ 或使用命名空间？ 还是只导出类型？ 我需要放置这些文件的特定位置吗？ 我需要设置哪些配置选项？ typeRoots ? types ? paths ? include ? 或者是什么？ - 到目前为止，我发现的所有内容都是令人困惑的错误消息、解释不清的配置选项和过时的 SO 问题。

标签： docs

缺乏离线文档

现代基本开发工具，如git或npm有自己的命令子集，允许我们访问离线文档/参考，例如：

$ git help ls-remote
$ npm help search 

我认为拥有这样的功能会很好（即使 TS 有点不同）。
这将允许我们通过help like 命令在本地浏览文档，而无需参考站点/github 等：

$ tsc help tsc # basic CLI arguments desc
$ tsc help config # opens up html page of the tsconfig.json docs
$ tsc help v3.5 # opens up html page changelog
$ tsc help enum # finds pages containing `enum` type and hints their names/opens them up

标签： offline , search , cli , local

这些示例需要一些更好的区分颜色！

应该如何：

const whomstve = (name: string) => name + 'is life'

目前情况：

const whomstve = (name: string) => name + 'is life'

有一点蓝色，但仅此而已。

大家好，我一直在关注这个问题，同时考虑了上个月的一般站点结构和整体文档。 现在这个问题已经解决了，我对我希望文档的样子有了更多的了解。

让我们尝试根据反应查看所有这些要点，并稍微调整一下以提高可读性。

API 文档有时只能存在于发行说明中

这个会很棘手，部分原因是现在我不确定发行说明中只包含哪些内容。

关于语言和语法，我希望通过新的即将面世的手册来修复和改进这个问题，该手册正在重新审视整个语言。 对于文档的其余部分，我认为一些新的站点地图应该涵盖大多数情况 - 但它仍然是一个 WIP

没有在网站上搜索

是的，我同意，这对于新站点来说绝对是至关重要的。

该网站是闭源的

固定的！ https://github.com/microsoft/TypeScript-website

新工作将从 master 分支上脱离，但现在旧站点可以在上面访问并接受 PR。 我也一直在将问题从 TypeScript 存储库转移到这里，因此更容易跟踪所有问题。

实用程序页面不是最新的

固定的！ 在某种程度上，我合并了很多 PR，并从社区获取了最新的手册。 以及确保它会显示在导航中（而不是仅来自网络搜索）

改进的 TS 配置选项说明

我在周末开始探索这个（我们如何确保编译器和网站为这些文档共享相同的初始数据源，以及网站可以在此基础上构建什么以提供更多上下文）

到目前为止的一些方向示例：

• 我自己 2017 年的笔记
• 我一直在和 Ethan Arrowood @matterhorndev聊天，他的tsconfig-ui可以作为创建 TSConfig 资源管理器的基础

游乐场不如替代品

固定的！ 我认为这是朝着我希望游乐场成为的大方向的积极垫脚石。 我有一些示例模型，它们提供了关于 Playground 应该是什么样子的更长远的观点，使其真正成为同类产品中的佼佼者。

（点击figma探索）

游乐场的可共享短网址

固定，见下文

没有类型名称词汇表

在学习编译器的过程中，我已经开始

[游乐场ex1，游乐场ex2]

不循序渐进地教授 TS

这旨在在新手册中解决，引用#29288的一些内容（滚动到New handbook ）

为所有用户编写通用文档很困难，因为 TypeScript 的受众广泛，而当前手册的优势（和劣势）之一是它试图同时为所有人服务。 我们有几个不同的开发者群体，他们在学习 TypeScript 时有着不同的期望，我们需要调整不同概念的暴露程度。 鉴于此，我们的目标是将手册分为三个不同的部分：

1. 量身定制的介绍（核心手册的设置）
   
   
   
   1. 核心手册（大家看这个）
   
   
   2. 参考页面（有点像深入研究/附录）
   
   

实际上，它有几个不同的起点，然后在您熟悉周围的生态系统后尝试教授语言。

这是否解决了评论中的所有问题？ 不，只是开始。 我目前拥有的站点地图非常广泛，这些是我感兴趣的问题类型

我在我当前的站点地图食谱和指南中留下了一些回旋余地，食谱是我们可以鼓励更多社区支持的东西。

提供指南

我花时间开始整理和更新当前在 TypeScript 网站上的代码示例。 我仍在弄清楚哪些样本最好留在我们这边，而不是重定向到官方文档（例如，如果一个项目现在原生支持 TypeScript，并且他们有自己的文档）

如上所述，我认为网站的食谱和实际指南部分应该足以涵盖这一点

语言规范已过时

是的，我不知道我是否可以从主存储库中彻底删除它 - 但它不会在新站点上被提及。

为代码示例提供更好的类似 IDE 的体验

这是目前在新的手册站点中，尽管我们也必须将其移植到新站点。 它还提供突出显示和内联错误消息，我对此感到很兴奋。

编译器错误索引页

不确定这种情况是否会发生，在某种程度上，TypeScript 有很多错误代码，而且它们会定期更改。 一旦有一个完全可用的站点和文档，它就值得回来，但现在它处于次要地位。

展示更多真实世界的例子

到目前为止，新手册在这方面做得很好👍🏾 - 我们可以努力保持这种状态。 对于其余的文档，我将尝试更改我认为是这样的任何内容。

网站的移动支持很弱

我正在考虑为新站点使用 Microsoft 设计系统（流体），这应该意味着移动支持（具有可访问性）应该“大部分免费”

像游乐场这样复杂的东西有点棘手，我认为对于手机大小的移动设备来说，浏览/探索的心态是一个很好的选择。 所以，我有一个更接近只读体验的模型：

探索 tsc 帮助改进

我对此持开放态度，但 typescript CLI 实际上只是一个命令，compile（这就是为什么不需要关于子命令的帮助的原因（尽管 --init 有点破坏了这一点））

提供有关改进 DTS 的建议

是的，我正计划将明确输入的网站合并到打字稿网站并整合这些文档。 他们中的_所有_是否会住在这个网站上还有待商榷。 有一些很好的理由将贡献的实际实现细节保留在明确类型的 repo 中，而高级概述可以存在于站点中。

整合文档/博客/发行说明

一个棘手的问题，我对博客/发行说明不太了解。 我们与其他人一起使用 Microsoft 产品博客系统，我不确定将所有这些都移到网站本身是否是个好主意。 我们可以计算出更接近时间的那个。

从更简单的方面来说，我绝对希望从 wiki 中删除此类信息，并将其仅保留在网站内（可以通过站点搜索对其进行索引）-我想离开 TypeScript wiki，专门用于贡献TypeScript 并使用 TypeScript 编译器 API（例如，当您import * as ts from “typescript”或构建语言服务器插件时）

涵盖最常见的错误

这与上述有关 - 对于这些类型的问题，有一个非常广泛的常见问题解答页面，我只是在 wiki 中才发现（使用 TS 3 年）。

我们可以以此为基准，并开始将它们与您的回复一起放入主网站

添加语法高亮

嗯，同意，谢谢！

总而言之，我认为我们已经积极探索或研究了很多这些，并且随着我们继续处理文档，我愿意提供更多反馈！

很棒的工作，非常感谢@orta ！

如何在 Playground 编辑器中借用/改进/协作 VSCode tsconfig 体验，而不是单独创建一个？

使 Playground 更好，现有的 VSCode 体验已经半途而废。

我不太确定你的意思。 喜欢 VS Code 中的自动完成 JSON 模式功能吗？ 我计划在 JSON 编辑器部分使用它，但是将每个选项作为带有标签的 GUI 的概述是查看所有选项和挑选的有用方法。

@orta当新手册成为官方手册时，指向当前手册部分的 URL 会中断吗？ 或者新手册会在不同的 URL 上吗？ 我只是想知道，因为在过去的几年里，我已经在 SO 答案中放入了大量的手册链接（我相信其他人也这样做了），如果它们都坏了，那将是不幸的。 （是否有更好的问题或地点来讨论一般文档迁移计划？）

@orta @jcalz想知道同样的事情，我有超过 2.5K 的 SO 答案，找到所有带有链接的答案并将它们全部更新是不可行的。 理想情况下，带有片段的链接仍然有效并重定向到新位置。 如果需要，我愿意帮助映射。

是的，我不相信破坏 URI - 有几个选项可以探索。

我认为它可能会为手册使用新的 URL 根（例如不是docs/handbook/x.html但可能是/handbook/x.html ），并通过地图使旧页面重定向到最接近的等价物某种。

我想知道这个存储库的所有 github 标签是什么意思。 其中一些是不言自明的，但另一些则不是。

例如，“Needs Proposal”我不清楚。 对于所有标签来说，像一些已经做的那样有更长的描述会有所帮助。

无法链接到 _specific_ 编译器选项的文档

我的团队对 TypeScript 相对较新，因此，我们的tsconfig.json经常更改，而且我经常想向人们指出特定编译器选项的文档，即以以下形式：

https://www.typescriptlang.org/docs/handbook/compiler-options.html#strict-null-checks
(or)
https://www.typescriptlang.org/docs/handbook/compiler-options.html#strictNullChecks

像这样的链接不起作用，但我希望它们起作用。

目前，我在该页面上唯一能看到的 HTML id 是 #compiler-options，它不是那么有用，因为它基本上位于最顶部 - 但是，为每个选项设置一个 id 将非常有助于人们了解页面的所需部分。

标签： compiler

@Tyler-Murphy 我们现在已经解决了

@ssalka - 是的，新的 tsconfig 文档中会有很好的称呼

——

我将关闭这个问题，一旦我们进一步了解手册和新站点，我将在未来以相同的前提重新打开一个新的 👍

打字稿游乐场：
我觉得我快疯了，但我找不到一个简单的“共享”选项来保存和共享我的项目（例如添加到 github 问题）。
我看到“导出”下的所有链接，但没有“共享”。

打字稿游乐场：
我觉得我快疯了，但我找不到一个简单的“共享”选项来保存和共享我的项目（例如添加到 github 问题）。
我看到“导出”下的所有链接，但没有“共享”。

示例：游乐场链接

新网站看起来真不错！ 但是我注意到这个请求（编译器选项的锚链接）没有在 😕

似乎这将是一个非常容易满足的要求，并且对新来者非常有帮助。 希望在未来的更新中看到它！