您是否在生成的输出上使用了其他一些捆绑工具，例如 browserify 或 webpack？ 还是您希望它直接在节点上运行？

如果这种行为是有意的，那么如何使用路径映射来解决相对导入地狱与节点的结合？

好吧，为了添加上下文，与 Node.js require()不同， "paths"设计用于允许重新映射的加载器。 预期的行为是允许 TypeScript 解析各种加载器使用的各种模块 ID 的类型信息，而不是重写模块 ID。 基本上它不会像你想象的那样做。 在我看来也不应该，它应该只能反映加载器的解析策略。

@mhegazy我希望它可以直接与节点一起使用。 它用于后端应用程序。 @kitsonk是否正确地说明这是按预期工作并且打字稿不会重写模块路径？

是的，这是为了减轻运行时和设计时体验之间的不匹配，当模块（因为它是由用户编写的）可以在运行时解决但编译器无法找到时。 此时编译器始终假定用户提供的模块 ID 是正确的，并且从不尝试更改它。

类似的响应https://github.com/Microsoft/TypeScript/issues/9910#issuecomment -234729007

好的，谢谢。 为了防止更多人感到困惑，更好地记录这一点可能很有用。 我现在使用https://www.npmjs.com/package/module-alias使其与节点一起工作。

感谢 TS 的立场，这里有一个简单的解决方案，可以解决我们这些使用 node 的 90% 用例，但希望方便地使用baseUrl相对require()调用而不大惊小怪。

此解决方案挂钩节点的require()调用，并使用 "main" 的目录名解析请求以模仿baseUrl 。 因此，它假定baseUrl编译器选项也设置为源“main.ts”所在的同一目录。

要使用，请将一小段代码粘贴到“main.ts”的顶部。

import * as path from 'path'
import * as fs from 'fs'
(function() {
  const CH_PERIOD = 46
  const baseUrl = path.dirname(process['mainModule'].filename)
  const existsCache = {d:0}; delete existsCache.d
  const moduleProto = Object.getPrototypeOf(module)
  const origRequire = moduleProto.require
  moduleProto.require = function(request) {
    let existsPath = existsCache[request]
    if(existsPath === undefined) {
      existsPath = ''
      if(!path.isAbsolute(request) && request.charCodeAt(0) !== CH_PERIOD) {
        const ext = path.extname(request)
        const basedRequest = path.join(baseUrl, ext ? request : request + '.js')
        if(fs.existsSync(basedRequest)) existsPath = basedRequest
        else {
          const basedIndexRequest = path.join(baseUrl, request, 'index.js')
          existsPath = fs.existsSync(basedIndexRequest) ? basedIndexRequest : ''
        }
      }
      existsCache[request] = existsPath
    }
    return origRequire.call(this, existsPath || request)
  }
})()

如果您要使用 mika-fischer 提到的module-alias包，请注意您注册到包的路径不应以/结尾，并且路径是相对于路径package.json在哪里（可能很明显，但最好弄清楚），

因此，如果您的 tsconfig 文件中有此内容：

"outDir": "./dist",
"baseUrl": ".",
"paths": {
  "foo/*": ["./src"]
}

您必须在package.json中注册：

"_moduleAliases": {
  "foo": "dist"
}

好吧，为了添加上下文，“路径”被设计用于允许重新映射的加载器，这与 Node.js 的 require() 不同。 预期的行为是允许 TypeScript 解析各种加载器使用的各种模块 ID 的类型信息，而不是重写模块 ID。 基本上它不会像你想象的那样做。 在我看来也不应该，它应该只能反映加载器的解析策略。

在浪费了一些时间试图在一个大项目中设置它之后来到这里。
如果此行为不会改变，您至少可以在关闭此问题之前更新文档。
官方文档https://www.typescriptlang.org/docs/handbook/module-resolution.html#path -mapping%20docs 并没有说明必须使用“允许重新映射的加载器”。

在您的项目文件夹中安装并运行“tspath”... https://www.npmjs.com/package/tspath

@ef-carbon/tspm

您也可以尝试“momothepug/tsmodule-alias”来别名路径解析：

https://www.npmjs.com/package/@momothepug/tsmodule -alias

只有https://www.npmjs.com/package/module-alias为我工作......

我也设法让它与模块别名一起使用，但缺点是我必须在 tsconfig.json 和 package.json 中跟踪我的别名。 有没有人找到更简单的解决方案？

@mattyclarkson指出的解决方案也有效，但我找不到将它与 ts-node 并排使用的方法。 有任何想法吗？

看看https://github.com/momoThePug/tsmodule-alias

2018-05-31 15:04 GMT-05:00 edufschmidt [email protected] :

我也设法让它与模块别名一起工作，但有缺点
我必须在 tsconfig.json 和
包.json。 有没有人找到更简单的解决方案？

@mattyclarkson 指出的解决方案
https://github.com/mattyclarkson也可以，但我找不到方法
将它与 ts-node 并排使用。 有任何想法吗？

—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393662306 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/ACKT9JWIkb0Wekz0H_Z3zKXvoE-49EIBks5t4EzkgaJpZM4J6vZQ
.

谢谢@DanyelMorales ，这真的很方便。

不客气！ :)

2018-05-31 16:35 GMT-05:00 edufschmidt [email protected] ：

谢谢@DanyelMorales https://github.com/DanyelMorales ，这真的是
便利。

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393688075 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/ACKT9GNo30wNv4ZWzSwm_Lv4vesLPI3xks5t4GIzgaJpZM4J6vZQ
.

如果发出的路径名实际上不正确，有人能告诉我这个功能的意义是什么吗？ 也就是说，如果 TypeScript 编译器对此感到满意，但最终结果无法运行 - 这个功能的用例是什么？

对于不是模块的东西，即不是导入的东西，应该如何做相对路径映射？

在一个节点脚本中，它读取相对于我以前执行的源文件的某个目录：

const starterDir = path.resolve(__dirname, './templates/starter')

由于 typescript 编译脚本并将其写入另一个目录（基于配置）， __dirname 将不再导致上述路径解析。 对此有什么解决方案？

对于不是模块的东西，即不是导入的东西，应该如何做相对路径映射？

这确实是“我如何使用 Node.js 和 TypeScript 问题”，在 Gitter.im 或 StackOverflow 中问得更好。

我喜欢 TypeScript，但这太疯狂了。

我不明白。 即使我对 TS 代码库知之甚少，这也不难实现。 我刚刚开始使用与客户端和服务器共享的项目......为什么 TS 首先呈现路径功能，然后让我跳过箍来实际使用它？ 为什么 TS 假设我想在我制作的每个项目中使用捆绑器/加载器？ 我正在尝试使用 TS 来简化我的项目，而不是添加更多工具库来补偿 90% 已实现的 TS 功能。

我同意你的看法。 我认为，TS 是为前端开发的，因为 webpack
已经很好地实现了 ts 别名路径，并且使用 Requirejs 也是
同一件事情。 但是对于 Nodejs 项目来说，这太难了。 :(

El jue.，9 月 20 日。 2018 年 2 月 50 日，Josh Pike通知@github.com
说明：

我不明白。 即使我对 TS 代码库知之甚少，这
应该不难实现。 我刚刚开始使用共享项目
与客户端和服务器...为什么 TS 会在
首先，然后让我跳过箍来实际使用它？ 为什么
TS 是否假设我想对我的每个项目都使用捆绑器/加载器
制作？ 我正在尝试使用 TS 来简化我的项目，而不是添加更多内容
工具库来补偿 90% 实现的 TS 功能。

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-423077950 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/ACKT9DD_z4KOHpfwddTomMXujEsza9tQks5uc0jbgaJpZM4J6vZQ
.

+1！

webpack 可以帮助我解决路径图（或其他工具，如babel-plugin-module-resolver ） ，但不能帮助我解决声明（ .d.ts ） 。

声明中的所有路径都未解析。

也遇到了这个问题。 发出的代码将包含路径映射似乎是合乎逻辑的。 诉诸module-alias 。 但是 +1 让 Typescript 可以选择性地提供此功能。

这不仅可以作为编译器选项添加吗？ 显然，这是一个受欢迎的要求。 对编译器的工作一无所知，实现它不应该超级简单吗？ 当 TypeScript 编译器可以很容易地直接解决这个问题时，为什么还要强迫我们跳过其他地方，这是最有意义的呢？

+1

您可以使用ts-transformer-imports和ttypescript将绝对和基于路径的 TypeScript 导入编译为相对 Javascript 文件

我创建了一个编译时解决方案，您可以在其中继续使用tsc 。 https://github.com/joonhocho/tscpaths

微软/TypeScript#15479（评论）

当我试图让 vue-cli 输出有很多import {foo} from "@/some/folder/foo"的 d.ts 文件并且输出的 d.ts 文件不解析别名时，我刚刚遇到了这个问题。

从一般搜索和查看此线程和其他线程来看，膝跳反应似乎是“这不是 TS 要解决的问题”，但我恳请团队改变这种立场，就像您使用自定义路径别名一样（完全有效且复杂项目的推荐方法）你根本不能使用生成 d.ts 文件（没有自定义的 3rd 方构建过程）所以我想说打字稿编译器也应该在声明文件过程中解析这些别名。

编译器的工作是为您的打字稿文件输出有效的 javascript 和 d.ts 文件，它在这种有效的场景中根本不起作用（在 tsconfig 文件中使用路径别名）。

我对这个问题有点困惑。 它已被关闭并标记为“按预期工作”。 我是否理解 Typescript 旨在输出无效源？ 似乎很奇怪。

乞丐不能成为选择者，但使用 Typescript 避免了原版 JS 的许多令人沮丧的方面，我将相对导入 ('../../../../../utils/parser') 视为其中之一。 如果 Typescript 可以清理这些，那就太棒了！

@codeitcody好像是这样。 愚蠢的是，它会输出一些没有第三方软件包根本无法工作的东西，但这就是现实。

好吧，这不是一个很好的问题。

有一个功能实际上会导致您的应用程序无法使用而不跳过箍（即安装更多依赖项来解决该问题），这似乎会适得其反。

这个问题已经存在 2 年了，关于它是否会被实施还没有官方消息。

考虑到这是在 Node.js 项目中使用 TypeScript 的最佳功能之一所必需的基本功能，它的处理方式非常糟糕。

@mhegazy你或其他人能否让我们知道两年后 TypeScript 团队是否会再次查看并重新考虑？

webpack 可以帮助我解决路径图（或其他工具，如babel-plugin-module-resolver ） ，但不能帮助我解决声明（ .d.ts ） 。

声明中的所有路径都未解析。

有没有办法做到这一点？ 我有一个自定义反应组件库，尝试使用paths作为别名时出现此错误。 我用汇总做 2 个捆绑包，用--emitDeclarationOnly做类型

我不能使用模块别名，因为它说：

警告：此模块不应在其他 npm 模块中使用，因为它会修改默认的 require 行为！

请帮助在 Reddit 上为这篇文章投票： https ://www.reddit.com/r/typescript/comments/a07jlr/path_maps_cannot_be_resolved_by_tsc_works_as/
不知道为什么它需要在这里进行如此大的讨论。 解决这个错误应该很容易。 tsconfig 中的一个选项，每个人都可以决定他想要的是当前行为（无论出于何种原因）还是一种工作方法。

我们在 Dropbox 遇到了同样的问题，并开源了这个转换器https://github.com/dropbox/ts-transform-import-path-rewrite

我现在有多次相同的经历，我希望路径别名能够得到解决，但我一直忘记我必须安装模块别名，更新 package.json 并将其导入主文件。 如果这是在 Typescript 的编译步骤中处理的，那就太棒了。

哎哟。 这对 TypeScript 来说是一个真正的打击。 这其中的意义在哪里？

ps 我们能不能只评论+1

欢迎来到俱乐部@def14nt。 我们是一群快乐的梦想家，当我们凝视更美好的未来时，我们满怀梦想，耐心地等待 TypeScript 实现简单而明智的编译器选项以使我们的生活更轻松的那一天。 当那一天终于到来时，一定要检查天空中猪的粉红色身体，因为它们雄伟地用新发现的翅膀飞向日落。

大声笑，我将为 TypeScript 团队可以添加支持的东西安装一个 npm 扩展。 也许他们应该停止添加越来越多的增强功能并添加这些基本功能。

@mika-fischer
如何使用https://www.npmjs.com/package/module-alias以便 eslint 停止警告“未解析的路径 '@root/bla/bla'（在 JS 文件中）？ 以及如何在 WebStorm 和 VS Code 中为此类路径启用自动完成功能？

对我来说，在打字稿项目中默认情况下自动完成导入在 VSCode 中工作。

@bobmoff是的，似乎一切都适合从 TS 文件导入 TS 文件。
但是 TS 文件中 `require('@root/bla/bla') 的自动完成和导航不起作用。

想把自己的js项目翻译成ts，想着可以把js文件一个一个重命名为ts。
现在我意识到 ts 和 IDE 都不支持它是如此困难和不支持，我应该立即将所有 js 文件重命名为 ts。

因为如果我只将一个 JS 文件重命名为 TS， build目录中的所有相对路径都会损坏（可能我应该使用“allowJs：true”，但我有一个项目包含 2 GB 的 JS 文件，它是如此将它们编译到构建目录 %)) 很奇怪。
好的，我试图通过模块别名来解决这个问题，我的 IDE 的导航和自动完成停止工作，并且 eslint 警告 100500 '未解决的路径'。 我已经有点讨厌TS了，看来大型JS项目的迁移并不像TS营销人员所说的那么容易。 似乎将 JS 后端项目迁移到 golang 更简单:)

我成功地使用tscpaths作为解决方法。

我也是。 我真的推荐tscpaths 。 它按预期工作。

我的简单解决方法：

node -r ts-node/register/transpile-only -r tsconfig-paths/register index.js

或者使用 pm2 process.yml

apps:
  - name: 'my-app'
    script: './dist/index.js'
    instances: 'max'
    exec_mode: 'cluster'
    out_file : '/dev/null'
    error_file : '/dev/null'
    node_args: ['--require=ts-node/register/transpile-only', '--require=tsconfig-paths/register']
    env_production:
      NODE_ENV: production

只是偶然发现了这一点，有时 TypeScript 可能会让人头疼。

我真的不明白为什么这个线程会一直持续下去......
我们都知道“路径地狱”，并且您（通过使用别名）可以
真的很干净
搞砸了，这个线程中的每个人都知道这一点！

别名由 TypeScript 编译器解释，它完全编译
正如它应该，
如果
你想用
别名你将不得不自己解决这个问题！

....或在 Apple、Google 和 Microsoft 启动线程
要求他们在其 JavaScript 引擎中实现功能，以便
他们能
解释你的别名;-)

TypeScript 编译器做的正是它应该做的！

如果您在 Angular 世界中工作，那么道路已经铺好，如果您想
运行你的
直接在 Node 中编写代码，您将需要一个工具来解析路径，我有
制成
这样的工具只为你，它已经在生产中使用了一年多，
它是
被瑞典最大的报纸使用，我做这个是为了你可以
裸奔
用 Node 做骨头，我不想在这里卖任何东西，我不赚钱
由此 ：）

是的，有像“tsmodule-alias”这样的工具和类似的黑客，你可以
实际上让它工作
如果你非常小心，但它很乱，有使用的变通方法
ts节点，
shell脚本等等等... yadda yadda

我终于觉得够了 所以我把自己锁起来
路径
编译时别名

> npm 安装-g tspatj

我的项目> tsc

我的项目> tspath

要么

我的项目> tspath --f

无头（在构建服务器上证明非常有用）

然后你就完成了，你的javascript文件现在有了
正确的相对路径，这不是我们想要的吗？

干杯! :)

https://www.npmjs.com/package/tspath

Den sön 1 月 13 日。 2019 kl 22:20 skrev 法比奥·斯潘皮纳托 <
通知@github.com>：

只是偶然发现了这一点，有时 TypeScript 可能是一个真正的痛苦
屁股。

—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-453866553 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAAy_7JYrwYo3KOLxpLWP0np5JVz2kQzks5vC6MogaJpZM4J6vZQ
.

@达夫曼

别名由 TypeScript 编译器解释，它完全编译
正如它应该的那样，它绝对不应该在生成的 javascript 中四处寻找，如果
你想使用别名，你必须自己解决这个问题！

非常不同意。 除非你在开玩笑，否则我真的看不出来。

TypeScript 应该编译_工作_的代码，而不需要第三方工具来完成仅在本机编译器中部分实现的工作。

TypeScript 编译器做的正是它应该做的！

如果这个帖子里到处都是要求tsc也做缩小或类似的人，我同意你的看法。 然而事实并非如此。 人们要求编译器生成可执行代码。 我真的不认为对编译器有太多要求，是吗？

如果您不使用以下功能，它会生成可执行代码
JavaScript 引擎不支持，这应该很有意义
那里，例如：如果你的应用程序，你会责怪 C++ 编译器吗？
使用动态链接库并且程序不会在机器上运行
没有安装这些？

如果您管理相对路径，则可以使用此功能，
像 Angular 对 WebPack 或我对它们负责一样
我所有使用 TSPath 的 TypeScript 项目！

如果您不了解如何设置工作环境，请不要使用它们，
我真的不认为这是微软的责任，他们
提供了一个功能，这是它的工作原理，
它可能无法按您的意愿工作或期望它可以工作，但这并没有
错了！

另外，我很好奇，你是否真的让这阻碍了你
使用 TypeScript 开发？

登门 1 月 14 日。 2019 kl 21:34 skrev Robert Main [email protected] :

TypeScript 编译器做的正是它应该做的！

如果这个线程充满了要求 tsc 也这样做的人
缩小或类似的，我同意你的看法。 然而事实并非如此。 它是
人们要求编译器生成可执行代码。 我真的
不要认为对编译器要求太多，是吗？

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454151277 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAAy_7FeuOJAnI9bXYSVgf_YghJluTyGks5vDOnEgaJpZM4J6vZQ
.

如果您管理相对路径，可以像 Angular 对 WebPack 那样对它们负责，或者像我使用 TSPath 对我所有的 TypeScript 项目那样对它们负责，这是一个可以使用的功能！

这是一个使编译器输出损坏的代码的功能，如果他们只编写了 1 行代码来正确解析这些路径，那么这些代码就可以工作。

TS 需要一个外部捆绑器才能执行输出的代码这一事实显然很荒谬。

如果您不使用以下功能，它会生成可执行代码
JavaScript 引擎不支持，

我一直都知道 TypeScript 应该编译成 JavaScript。 如果您告诉我 JavaScript 引擎不支持某些功能，那么它们究竟为什么存在呢？

如果您的应用程序动态链接库并且程序不会在没有安装这些的机器上运行，您会责怪 C++ 编译器吗？

不，但如果它让我链接到其他实际上不存在且没有编译器错误或警告的 C++ 代码，我会责怪它。

你真的不明白这一点，是吗？ 代码没有被破坏，如果它是
坏了是因为你已经配置了编译器
生成您的“平台”不支持的代码，在这种情况下，
别名！

在你的情况下，不要使用别名，“你”不支持他们，认真的！

即使这将是 1 行修复（当然不是这种情况）它是
关于编译器应该和
不应该做！ 添加此功能是为了不支持装载机
反过来，阅读
关于官方文档中的路径映射，所以再次，您正在使用它
错误的！

同样，此功能适用于 Loaders/Resolvers，您误解了它是如何使用的
有效，所以不，微软
不应更改编译器，以便您可以粘贴别名而不使用
支持它的环境！

丹蒂斯 1 月 15 日。 2019 kl 04:41 skrev 法比奥·斯潘皮纳托 <
通知@github.com>：

如果您管理相对路径，则可以使用此功能，
像 Angular 对 WebPack 或我对它们负责一样
我所有使用 TSPath 的 TypeScript 项目！

这是一个使编译器输出损坏代码的功能，代码
如果他们只编写 1 行代码来解决这些问题，就可以工作
路径。

事实上，TS 需要一个外部捆绑器，以便输出的代码
可以被处决是荒谬的。

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454256799 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAAy_zuWKV0qzzWt6_jZNgDLFt1TA0tMks5vDU3vgaJpZM4J6vZQ
.

它们在那里是因为加载器使用路径映射，这就是支持它的原因！
既然你坚持（像我一样）在没有加载器的情况下使用它们，那么什么是
有问题
使用工具，以便您可以使用该功能？

丹蒂斯 1 月 15 日。 2019 kl 05:10 skrev Robert Main [email protected] :

如果您不使用以下功能，它会生成可执行代码
JavaScript 引擎不支持，

我一直都明白 TypeScript 应该编译成
JavaScript。 如果您告诉我某些功能不受
那么 JavaScript 引擎为什么会存在呢？

如果您的应用程序动态链接，您会责怪 C++ 编译器吗
库并且程序不会在机器上运行没有这些
安装？

不，但如果它让我链接到其他没有的 C++ 代码，我会责怪它
实际上存在没有编译器错误或警告。

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454260977 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAAy_25-ZmS235i1Ic7mvSzEt2QJDX6Bks5vDVTAgaJpZM4J6vZQ
.

听着，我明白你的意思了。 我愿意。 但是编译器的一部分工作是最后一次进行完整性检查。 充其量编译但不运行的代码是不一致的行为，当我第一次阅读这个问题时，文档似乎暗示了明显不存在的行为

请指出我的文档的那部分。

是 1 月 15 日。 2019 吉隆坡。 05:31 skrev Robert 主要通知@github.com：

听着，我明白你的意思了。 我愿意。 但是编译器的一部分工作是保持理智
最后检查一次。 充其量可以编译但不运行的代码是
不一致的行为，当我第一次阅读这个问题时
文档似乎暗示了明显不存在的行为

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454263854 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAAy_8e5v8IV-ynmjRTeoC3cp5llwnsIks5vDVm8gaJpZM4J6vZQ
.

添加此功能是为了不支持装载机
反过来，阅读
关于官方文档中的路径映射，所以再次，您正在使用它
错误的！

https://austinknight.com/wp-content/uploads/2015/04/DesignVSUX.jpeg

@duffman你看不到这里的人只是想要这个功能吗？？？ 您是在告诉每个人，他/她很愚蠢，无法理解应如何使用此“功能”。 好的——你可以这样看，但谁知道呢——也许反过来……

顺便说一句，我的意见如下：

由于别名是内置在编译器中的，并且使用它们编译项目是可以的。 它可能会让用户认为，它按照它所建议的方式工作（这个问题很好地证明了我是对的）。 甚至看起来不合逻辑-为什么某些东西在“官方”编辑器中有效（vscode-特别是在使用“自动导入”功能时，vscode 使用别名路径），为什么编译器也可以正常工作，当结果代码不工作时？ 说“js引擎不支持它”让我想问更多——TS不是为了缓解一些JS“问题”吗？

我希望这是以下两种解决方案之一：
1) 使用别名正确覆盖导入
2) 显示警告

我认为说“这是正确的行为”是错误的。 它不是。 TS 不是汇编语言，甚至不是 C/C++。

开发团队应添加对别名解析的支持。 我建议添加一个
tsconfig 中编译器解析的关键。

这将是很好的微软！！！！！！！

我们求求您，我们需要您的帮助来改进使用别名的应用程序。

:(这里的每个人都悲伤和愤怒（和饥饿）因为滞后
一致性。 打字稿很棒，我喜欢它...

我们喜欢它！

最好的问候无家可归的开发商...

El mar., 15 de ene。 de 2019 08:02，Mike S. [email protected]
说明：

顺便说一句，我的意见如下：

别名是编译器内置的，编译是可以的。 可能会让用户
认为，它应该像他们想的那样工作（这个问题几乎
很好的证明这是真的）。 这似乎不合逻辑 - 为什么有些东西在起作用
“官方”编辑器（vscode - 特别是在使用“自动导入”功能时，
vscode 使用别名路径），为什么编译器在生成代码时也可以正常工作
不管用？ 说“js引擎不支持”让我想问
甚至更多 - TS 不是为了缓解一些 JS “问题”吗？

我希望这是以下两种解决方案之一：

1. 使用别名正确覆盖导入
2. 显示警告

我认为说“这是正确的行为”是错误的。 它不是。 TS 不是
汇编语言，甚至不是 C/C++。

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454384357 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/ACKT9OqexgOaHH1vDFuRcO7U_r2DEC23ks5vDdFbgaJpZM4J6vZQ
.

. TS 不是汇编语言，甚至不是 C/C++。

我真的不明白你想通过确定 TS 不是 C++ 来指出什么，我们大多数人都清楚我认为！

我们还确定了别名/路径映射在世界各地的生产中都使用，所以自然地，VS Code 应该支持这一点，但它仍然不是 MS 制作适合您的设置的编译器的论据！

我很难理解的是为什么要坚持下去，编译器会按预期工作，再次阅读清楚说明该功能用途的文档！

我的意思是你可以在 2 分钟内建立一个带有路径别名的工作 TS 开发环境，如果你不想使用 WebPack，你可以使用 TSPath 在 1 秒内解析所有 js 文件中的所有路径，将其添加到包中.json 作为一个运行脚本，你甚至不必考虑它，问题不存在，编译器保持它原本的功能，你可以继续快乐！？

或者，如果实际的编译器为您执行此操作对您来说非常重要，那么我建议您分叉编译器并自己实现它，也许它会很受欢迎，或者人们可能会因为他们已经设置而感到高兴他们的环境支持别名。

召集前五名 TypeScript 贡献者： @ahejlsberg @andy-ms @DanielRosenwasser @sandersn @sheetalkamat

TypeScript 团队可以重新考虑这个问题吗？ 我认为这个线程对这两种观点都提供了一些有用的讨论，并且考虑到它最近的流行度和经过的时间量，应该再次查看它。

这个问题的状态让我别无选择，只能将 TS 降级为类型检查员职责。
Babel 现在对 TS 语法有了不错的支持，并且与babel-plugin-module-resolver一起可以很好地为这个用例发出工作代码。
唯一的缺点是从tsconfig.json复制一些配置，因为 Babel 不关心 TS 配置。 但对于在节点项目中使用绝对路径来说，这是一个可以接受的价格，而且作为奖励，我可以通过 babel 宏之类的出色功能获得整个生态系统。

这是我作为tsc编译器的替代品的最低设置：

• npm install --save-dev @babel/cli @babel/core @babel/preset-env @babel/preset-typescript babel-plugin-module-resolver @babel/plugin-proposal-class-properties @babel/plugin-proposal-object-rest-spread
• 在package.json ：
  tsc -> tsc && babel ./src --out-dir ./dist --extensions ".ts,.js"
• 在tsconfig.json ：

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@mynamespace/*": ["src/*"]
    },
    "outDir": "./dist",
    "noEmit": true, <--
    "allowJs": true,
    "target": "ES2017",
    "module": "CommonJS",
    "lib": [
      "ES2017"
    ]
  },
  "include": [
    "./src/**/*"
  ]
}

• 在.babelrc ：

{
  "presets": [
    "@babel/preset-typescript",
    ["@babel/preset-env", {
      "targets": {
        "node": true
      }
    }]
  ],
  "plugins": [
    ["module-resolver", {
      "root": ["./src"],
      "alias": {
        "@mynamespace": "./src"
      },
      "extensions": [".js", ".ts"]
    }],
    "@babel/plugin-proposal-class-properties",
    "@babel/plugin-proposal-object-rest-spread"   
  ]
}

我只是想用绝对路径的打字稿，但似乎我必须配置 webpack 或 babel 什么的，实现这个简单的功能太难了，应该更容易😞

我承认这个问题，我不确定我是否已经意识到这个具体问题
由于我自己的个人设置引起的问题，或者我可能是:) 这不是超级
重度修复，修复将只是简单地（盲目地）信任 distPath，
这实际上是比当前解决方案越来越简单的代码，我会
尝试在明天之前修复...

登门 1 月 28 日。 2019 kl 15:59 skrev 叶伟伟[email protected] :

我只想使用带有绝对路径的打字稿，但似乎我必须
配置 webpack 或者 babel 什么的，太难了！！！

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-458164055 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAAy_1_T-An7swSND-xdBhL0HNHxQkm6ks5vHxBggaJpZM4J6vZQ
.

将其留在这里是因为此线程中未提及paths当前行为的实际记录用例： @types/包不支持与 semver 相关的功能。 但是，它们确实包含我可以使用的旧 API 的更新类型。 例如，当history@3是最新的时，我正在使用history@2 。

"paths": {
    "history": [ "history/v2" ]
}

编译器需要一个额外的选项来区分类型别名和“代码”别名。 如果我们将行为更改为实际发出路径别名，那么我们需要向编译器添加查找正确类型版本的能力。

这不是反对提议的行为的论据。 我宁愿发出别名和 just™ 用于类型版本控制的工作解决方案。 只是想提供一些背景信息，为什么改变它可能不像人们想象的那么简单。

在全公司范围内的 TS 研讨会上，我第二次不得不解释这种愚蠢和尴尬的行为......

严重地！

什么样的语言编译器，尤其是主要推销对 JavaScript 更正确的语言编译器，会产生损坏的代码作为“功能”？！？！

很抱歉，我的评论听起来如此沮丧，但社区的观点似乎一再被忽视和淡化。

看看这被引用了多少次......对于这么多人来说，这是多么浪费时间和注意力。

我理解你的沮丧，但很多人认为一种行为是正确的，并不意味着它是正确的做法。

TypeScript 重写模块标识符是一个滑溜溜的斜坡。 在这个线程中多次表达的是，TypeScript 可配置为模拟其他模块解析器和其他构建工具的行为，而不是替换或实现它们。

仅仅因为 TypeScript 可以配置为以灵活的方式解析模块并不意味着 TypeScript 会发出“损坏的代码”。 镜像此配置的某些加载器和捆绑器可以正常工作。

如果我们要批评任何事情，我们可以责怪团队将选项命名为某些看起来像是修复了一个从未打算修复的问题，尽管该选项的文档清楚地表明它不会改变发射.

因为一个特定的工具不能解决你遇到的问题并不总是意味着工具有问题。 也许您只是没有解决问题所需的所有工具。

@kitsonk你刚才说的一切都离题了。

问题是 TS 将在开发/测试期间以一种方式运行，而在编译完成后另一种方式运行。

如果 TS 想成为一个模块解析器，它需要选择一个模式并坚持下去。 如果我用ts-node运行某些东西，它应该像我编译一些 TS 并用node运行它一样运行。

它没有，这就是问题所在。

也许模块映射会在未来减轻这种挫败感。 但是我们在这里的立场以及我们想要解决的技术问题非常明确 - 路径映射反映了外部解析方案的行为（例如 AMD 和 System.js 中的路径映射，Webpack 和其他捆绑程序中的别名）。 这并不意味着我们会改变你的道路。

我认为最近的任何讨论都没有建设性，我也没有预见到这里未来的任何变化，所以我将锁定这个问题。