CLI开发工具语言运行时【免费下载链接】tsx⚡️ TypeScript Execute | The easiest way to run TypeScript in Node.js项目地址https://gitcode.com/gh_mirrors/ts/tsx点击查看免费下载导读本文以仓库内研究笔记 notes/oxc-resolver/module-resolution.md 为核心骨架系统解析 oxc-resolver 的扩展名别名extensionAlias配置机制它如何从 enhanced-resolve 移植选项、如何通过有序别名列表实现 TypeScript 优先解析、为什么该策略是“调用方策略”而非解析器全局默认以及 packageimports/exports目标如何统一复用同一套别名文件加载器。读完本文你将理解 oxc-resolver 在 Web 工具链打包器、运行时、语言服务中处理./value.js与./value.ts映射关系的完整决策链路并能准确判断在何种场景下配置extensionAlias才会生效。oxc-resolverenhanced-resolve 的 Rust 移植oxc-resolver 是 oxc 项目Rust 生态下的 JavaScript/TypeScript 工具链提供的模块解析器其核心定位是移植 enhanced-resolvewebpack 的解析器的配置选项体系。这条继承关系是理解本文所有行为的前提选项名、默认值与 enhanced-resolve 保持对齐降低从 webpack 工具链迁移的认知成本由于使用 Rust 实现它服务于需要高性能解析的打包器、运行时与语言服务等场景。这一移植事实有明确的源码依据oxc-resolver 的src/options.rs从 enhanced-resolve 移植选项定义notes/oxc-resolver/README.md亦将本笔记定位为 oxc-resolver configuration behavior relevant to TypeScript extension aliases。在 tsx 仓库中该笔记归属于 notes/oxc-resolver/ 工具专有文件夹与 notes/enhanced-resolve/module-resolution.md 构成“同域同名文件”的对照研究——这也是仓库 notes/README.md 规定的证据组织方式。默认扩展名无 TypeScript 替换的.js、.json、.nodeoxc-resolver 在没有配置extensionAlias时默认只解析三类扩展名默认扩展名说明.jsJavaScript 源文件/产物.jsonJSON 数据文件.nodeNode 原生模块关键在于默认行为中不存在任何 TypeScript 扩展名替换。也就是说当导入语句写成import ./value.js时解析器只会查找真实的value.js文件而不会自动尝试value.ts。这与 webpack 生态中“需要显式配置 TypeScript 相关 resolve 规则”的习惯一致——TypeScript 优先解析TS-first是显式配置的结果而不是解析器的出厂默认值。该默认值定义在 oxc-resolver 的src/options.rsdefaults部分即#[derive(Default)]对应的扩展列表由notes/oxc-resolver/module-resolution.md原文明确记录。extensionAlias有序的“调用方策略”配置语义有序列表先命中先胜出extensionAlias是 oxc-resolver 的核心配置项用于把一个已写出的扩展名映射为一组候选扩展名。它是一个有序列表ordered list解析时按列表顺序逐个尝试第一个命中即胜出。典型配置也是 oxc-resolver 官方测试使用的配置{ extensionAlias: { .js: [.ts, .js] } }这一配置表达的策略是遇到./value.js时先尝试./value.tsTypeScript 优先若value.ts不存在再回退到./value.jsJavaScript 兜底。oxc-resolver 的扩展名别名测试位于src/tests/extension_alias.rs正是使用.js: [.ts, .js]这一顺序将“TypeScript 优先、JavaScript 兜底”的行为显式化——而非依赖默认值。这里的“显式化”是重要提示开发者必须自己写出[.ts, .js]顺序解析器不会替你推断应该先找 TypeScript。为什么称其为“调用方策略”笔记原文将extensionAlias定性为ordered caller policy有序的调用方策略。这里的“调用方策略”有两层含义由配置方决定顺序别名列表的顺序完全由配置者打包器作者、框架作者掌控解析器只忠实执行不内置任何“TypeScript 优先”的价值观与解析器全局选项形成对照oxc-resolver 的ResolveOptions是**解析器全局resolver-global**的即一套配置作用于整个解析器实例而不是按单次请求resolve request动态切换。这与 enhanced-resolve 形成有趣的对照。在 enhanced-resolve 中extensionAlias同样是有序调用方策略见 notes/enhanced-resolve/module-resolution.md其测试亦使用.js: [.ts, .js]顺序来“偏好 TypeScript 并回退到 JavaScript”。这说明两个解析器在“有序别名”这一核心语义上保持一致。解析管线别名检查先于精确文件检查oxc-resolver 文件解析管线的关键顺序是extension_alias在检查精确文件exact file之前执行。这意味着即使磁盘上真实存在value.js只要配置了.js: [.ts, .js]解析器仍会先用value.ts替换掉既有目标。也就是说别名替换拥有比“精确命中”更高的优先级——这不是“找不到 .js 才找 .ts”的兜底逻辑而是“无论 .js 是否存在都按别名顺序优先找 .ts”的抢占逻辑。这一行为有明确的实现证据文件管线逻辑位于 oxc-resolversrc/lib.rsfilepipeline 相关段落即 pipeline 中extension_alias分支先于精确文件检查别名加载器alias loader实现位于src/lib.rs的 alias 文件加载函数中负责把映射后的候选路径送入后续解析阶段。与 tsx 运行时策略的本质差异值得强调的是这种“别名先于精确”的构建期/配置期策略与 tsx 作为运行时执行器的解析策略有本质区别。tsx 的目标是保留 Node 的运行时契约runtime contract其策略记录在 notes/tsx/module-resolution.mdtsx 的扩展名替换映射为.js - [.ts, .tsx, .js, .jsx]、.jsx - [.tsx, .ts, .jsx, .js]、.mjs - [.mts]、.cjs - [.cts]实现于 src/utils/extension-resolution.tstsx 对ESM JavaScript 依赖采用“精确文件优先缺失时才回退 TypeScript”的策略——即运行时依赖解析不会用.ts抢占已存在的.js产物见 notes/tsx/module-resolution.md 中的决策矩阵以及 ESM 解析器 src/esm/hook/resolve.ts 中的分类与重试逻辑tsx 还维护“原样扩展名verbatim extension”集合.ts、.tsx、.mts、.cts禁止对已有 TypeScript 扩展名继续追加猜测如x.ts.ts这一约束由 tests/specs/resolution-priority.ts 中的“verbatim TS extension wins over appended-guess file”测试族锁定。简言之oxc-resolver 的extensionAlias是配置驱动的、别名抢占式的构建期策略tsx 的扩展名替换是运行时契约驱动的、按父模块类型分类的策略。二者解决的是不同阶段的同类问题不可混为一谈。全局选项与 NAPI 边界请求不带调用方上下文笔记原文特别指出两个边界事实ResolveOptions是解析器全局的extensionAlias等选项一旦设置就对整个解析器实例的所有解析请求生效不存在“这次请求用别名、那次请求不用”的按请求切换机制NAPI 请求不携带调用方策略上下文oxc-resolver 的 NAPINode API绑定在napi/index.d.ts中声明的接口只接收解析器配置与请求参数无法表达“本次调用希望使用不同的别名顺序”这类调用方细粒度意图。这两个事实共同决定了 oxc-resolver 的使用模型如果你想在同一个进程中同时服务“TypeScript 优先”和“JavaScript 优先”两类请求必须创建两个携带不同ResolveOptions的解析器实例而不是在单实例上动态切换。这也是“ordered caller policy”中“caller”的真正落点——策略在创建解析器时由调用方一次性注入而非在每次解析请求时注入。packageimports与exports统一复用别名文件加载器extensionAlias的另一个关键行为是包级映射选择之后imports和exports目标都会重新进入同一个别名文件加载器。解析流程可以概括为两段式映射选择map selection根据 specifier 命中 packageexports或imports映射得到目标路径文件加载aliasing file loader目标路径进入统一的、带extension_alias处理的文件加载器此时别名替换生效。实现证据位于 oxc-resolversrc/lib.rsimports目标在映射选择后进入别名加载器exports/共享加载器同样在映射选择后复用同一别名加载器。与 enhanced-resolve 的差异exports 默认也走别名这里存在一个值得注意的移植差异在 enhanced-resolve 中imports目标默认接收扩展名别名而exports目标默认保持精确匹配除非显式启用extensionAliasForExports选项见 notes/enhanced-resolve/module-resolution.md。也就是说enhanced-resolve 对imports和exports施加了不对称的别名策略。而 oxc-resolver 的ResolveOptions没有暴露 target-specific按目标区分的扩展名别名开关——imports与exports目标统一走同一套别名文件加载器。这意味着在 oxc-resolver 中无法像 enhanced-resolve 那样单独关闭 exports 目标的别名替换。这一差异对工具链作者有直接影响如果你的打包器或框架依赖“exports 目标必须精确匹配发布产物如./metadata.min.json”的语义在迁移到 oxc-resolver 时需要在解析器层面评估全局extensionAlias是否会意外改写 exports 目标而不是寄希望于按目标开关。tsx 在运行时侧对此类“JSON 资产必须精确命中、缺失即失败”的资产选择策略有明确边界见 notes/tsx/module-resolution.md 的 JSON 决策说明可作为对照参考。关键结论与实践建议默认值oxc-resolver 默认只解析.js、.json、.node不内置任何 TypeScript 替换显式配置TypeScript 优先行为必须通过extensionAlias显式声明例如.js: [.ts, .js]顺序即优先级别名列表有序先命中先胜出列表写在前面的扩展名会抢占磁盘上真实存在的后面扩展名文件全局生效选项是解析器全局的NAPI 请求不携带调用方上下文需要多策略并存时应创建多个解析器实例imports/exports 统一包级映射选择后统一进入别名文件加载器且ResolveOptions无 target-specific 开关——与 enhanced-resolve 的extensionAliasForExports机制存在差异与 tsx 对照oxc-resolver 的别名抢占式策略适用于构建/配置期tsx 作为运行时执行器采用父模块分类策略TypeScript 父模块 TypeScript-first、运行时 JS 依赖精确优先相关实现与测试可继续参阅 src/utils/extension-resolution.ts、notes/tsx/module-resolution.md 与 tests/specs/resolution-priority.ts。最后若要进一步研究增强版对照行为可继续阅读同域研究笔记 notes/enhanced-resolve/module-resolution.md其中完整记录了 enhanced-resolve 的extensionAliasForExports开关、别名先于精确文件检查的管线顺序以及 imports/exports 不对称策略的源码位置与本文的 oxc-resolver 结论互为印证。赞分享CLI开发工具语言运行时【免费下载链接】tsx⚡️ TypeScript Execute | The easiest way to run TypeScript in Node.js项目地址https://gitcode.com/gh_mirrors/ts/tsx点击查看免费下载相关推荐tsx 研究笔记oxc-resolver 的 extensionAlias 扩展名解析配置与 TypeScript 解析顺序剖析tsx 研究笔记oxc resolver 的 extensionAlias 扩展名解析配置与 TypeScript 解析顺序剖析 tsxTypeScriptCLI开发工具语言运行时enhanced-resolve 模块解析研究TypeScript 扩展名别名extensionAlias的配置语义与执行顺序enhanced resolve 模块解析研究TypeScript 扩展名别名extensionAlias的配置语义与执行顺序 本文基于 tsx 仓库研究CLI开发工具语言运行时Sunshine游戏串流完全指南如何打破设备限制随时随地畅玩PC游戏Sunshine游戏串流完全指南如何打破设备限制随时随地畅玩PC游戏 你是否曾经想过在客厅的电视上玩电脑游戏却不想把沉重的PC搬到客厅或者想在出差时用CLI开发工具语言运行时上一篇dromara/disjob的连接池数据库与Redis资源复用下一篇Cherry Studio 完整指南从分支策略到Pull Request的协作开发流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考