ts-loader 报 TS18003：外置 tsconfig 的 context 要指向项目根目录

Webpack 使用 ts-loader 构建时，提示 TS18003: No inputs were found in config file。项目里明明有 TypeScript 文件，把 tsconfig.json 移到项目根目录却能构建；一旦通过 configFile 指向独立配置目录，又找不到输入文件。这种场景应先核对配置解析的基目录。

configFile 决定读取哪个配置文件，context 决定 ts-loader 解析其中相对路径时使用的基目录。只指定配置文件的绝对路径，并不会自动让它以业务项目根目录寻找源码。

配置存在，输入文件仍可能不在搜索范围

检查失败构建实际加载的 Webpack 配置，记录 ts-loader 的 configFile、context，以及该 tsconfig 的 include、exclude 和 files。默认情况下，ts-loader 以配置文件所在目录作为解析基目录。

例如，业务源码在项目的 src 目录，共享 tsconfig 却放在另一个目录。该配置中的相对搜索范围可能落到配置目录下面，根本覆盖不到业务源码。TS18003 表示解析后的配置没有找到输入文件，不表示磁盘上的全部 TypeScript 文件都已消失。

先确认 tsconfig 路径没有拼错，再判断每个匹配规则相对于哪个目录展开。如果配置已经在项目根目录，也设置了正确的 context，就继续检查规则是否确实覆盖现有文件、文件是否被排除，以及 CI 工作目录是否缺少源码。不要仅凭错误码添加一个空 TypeScript 文件来隐藏配置问题。

为外置配置明确项目根目录

以下是 CommonJS Webpack 配置中应合并到现有 rules 的示例。假定 webpack.config.js 在业务项目根目录，而共享配置位于 config/tsconfig.json：

const path = require('path');

module.exports = {
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        exclude: /node_modules/,
        loader: 'ts-loader',
        options: {
          configFile: path.resolve(__dirname, 'config/tsconfig.json'),
          context: path.resolve(__dirname)
        }
      }
    ]
  }
};

这里 context 必须是绝对路径，并指向实际的业务项目根目录。Webpack 配置本身放在配置子目录时，__dirname 就是那个子目录，需要另行计算项目根目录，不能原样照抄。

改变基目录后，还要检查 tsconfig 中的相对路径是否与新基准一致。原来为配置文件位置写的相对路径，未必仍然正确。示例只展示 loader 的组织方式，应保留原项目的 entry、plugins、输出设置及其他规则，不要整份覆盖。

使用多个 loader 时，将 loader 与它的 options 放在 use 数组内的同一个对象中。若出现 options/query provided without loader，应先修正 Webpack 规则结构；这与 TypeScript 找不到输入文件是不同错误，继续改 context 无法修好错误的 loader 写法。

编辑器与 ts-loader 可能读取不同配置

独立共享配置可以供多个项目复用，但编辑器和直接运行 tsc 的行为不一定与 ts-loader 相同。项目根目录可保留自己的 tsconfig.json，通过 extends 继承公共配置，并在项目层明确需要覆盖的设置。

要核对构建是否真的读取了这份项目配置。如果 ts-loader 的 configFile 仍然直接指向公共文件，根目录扩展文件里的修改不会因此自动进入 loader；只为编辑器添加文件，却认为构建也已经切换配置，会留下两套不同的输入范围。

公共配置被多个项目共享时，优先在项目的 loader 配置中修正 context，避免为一个项目改动公共 include 后影响其他项目。变更前保存 Webpack 配置和相关 tsconfig，回退时恢复整组对应配置。

验收要看到预期源码进入检查

用原来失败的构建入口重新检查，确认 TS18003 消失，预期入口文件和依赖的 TypeScript 文件都进入正确的检查范围。随后核对编辑器与命令行使用的配置，确保它们没有因为搜索基准不同而忽略另一批文件。

出现新的类型错误，可能说明此前漏掉的文件终于被检查到，不能为了恢复绿色构建重新排除它们。若输入仍为空，返回实际 configFile、context 和展开后的路径继续定位；删除缓存或重装全部依赖不能替代这项路径核对。