TypeRunner 是一个高性能 TypeScript 编译器。
Goals
- 解析器
- 类型检查（作为 CLI 和库）
- 语言服务器
- 交互式类型调试
- 用其他语言输入信息
- （可选）转译为 JavaScript
- （可选）JavaScript 中的 RTTI
- （可选）类型分析器
此外，使TypeScript类型检查尽可能快，并为其他语言提供一个本地库，这样他们就可以使用TypeScript类型信息，而不需要JavaScript引擎，使各种用例，如JSON-Schema替换，ORM DSL，编码信息（如Protocol Buffers模式）等等。
Non-goals
- 替代官方 TypeScript 编译器
- 运行
作为整个官方 TypeScript 编译器 (tsc) 的直接替代品，需要复制 tsc 的设计限制、错误和遗留决策。由于 TypeScript 已有 10 年的历史，因此有许多功能在今天是不必要的，但为了兼容性而保留。该项目专注于 TypeScript 的一个更严格的子集，这意味着 TypeRunner 将不支持某些功能，例如 JSDoc 和几个编译器选项。
初始版本中的源代码实际上只是一个概念证明。它由大约 30k LoC 组成，并显示出非常有希望的结果。方法是使用 TypeScript 到字节码的编译器，然后在自定义虚拟机中运行字节码。数据表明，这种方法可以使速度提高几十倍到几千倍。
TypeRunner 目前只支持非常基本的类型表达式：原语、变量声明、（通用）函数声明、一些类型函数，如类型别名、（分布）条件类型、模板文字、数组/元组、索引访问、联合、以及一些其他东西。
TypeRunner 现下的开发几乎停滞不前，更多的是一个实验/概念证明。一旦项目通过社区获得资金，开发将继续。
-
TS 作为 JS 的超集能否提高 JS 的性能或者降低生产出错的概率 ？是否值得去坚持使用 ？最近项目初始化的时候用 Vite 选的就是 TS 但项目有很多稀奇古怪的需求，导致 TS 各种报错提示什么的，有点拖慢进度，所以内心有些动摇了，TS 是否值得坚定的使用下去 ？规范问题不用太担心，我自己是强迫症，代码不会乱七八糟，我就怕性能和隐性的报错，请大佬指教，我自己用的是 React
-
TypeScript 提供了很多不同功能的编译选项，既可以通过配置 tsconfig.json 文件中的 compilerOptions 属性来实现编译，也可以使用在 tsc 命令后跟随参数这形式，直接编译 .ts 文件。 注意： 当命令行上指定了输入文件时，tsconfig.json 文件会被忽略。 1. 慕课解释 我们通过编译选项 --watch 为例，在当前目录创建 main.ts 文件，写
-
背景： 在vue3+ts+vite项目中： vue文件：import.meta.env代码能正常访问 ts文件：import.meta.env文件有编译报错 尝试1： 在tsconfig.json中添加"types": [ "vite/client" ]
-
所以我看到它找不到promise和地图。
-
高级编译 常规构建过程使用Google的在线JavaScript编译器将Blockly减少到六个文件，总计约720kb（压缩后的160kb）。 另外，也可以在“高级编译”模式下使用Google的离线JavaScript编译器，它具有许多优点： 由于文件结构改变，总块大小减少到300kb（压缩了100kb） 由于本地编译器的执行，构建时间更快且没有网络流量 无限编译（在线编译器受速率限制） 设置 出
-
我们在当前项目中使用GWT 2.4版。在服务器端，我们使用Spring 我们使用Maven作为构建工具。该应用程序正在JBOSS 7服务器上部署。 目前，我们在一个Eclipse项目中拥有所有内容。指一个应用程序。gwt。xml文件和一个ApplicationContext。spring的xml。我们有大约2000个Java文件，其中大约1500个用于GWT相关的源文件。 该项目仍在增长，源文件越