使用GNU Make构建TypeScript工作流时的文件打包异常问题

1. Makefile 依赖规则逻辑有问题 #

你用.compiled作为编译完成的标识，但如果pkg/a.js只依赖.compiled、没直接绑定对应的js/a.js，很容易出现时间戳判断异常：

• 修改单个src/a.ts后，tsc全量编译会更新js/a.js的时间戳，随后你更新.compiled的时间戳。
• 要是pkg/a.js的规则写的是pkg/a.js: .compiled，Make只会判断.compiled是否比pkg/a.js新，若tsc生成js/a.js的时间因文件系统延迟、或tsc未正确更新时间戳，导致其比上次pkg/a.js的生成时间还早，第一次执行Make时会误以为js/a.js没变化，跳过打包；第二次执行时时间戳同步完成，才会触发打包。
• 调整方案：让pkg/a.js直接依赖对应的js/a.js，同时保留.compiled确保全量编译的完整性，示例Makefile规则：

  js/%.js: src/%.ts
      tsc --outDir js src/$*.ts
  .compiled: $(wildcard js/*.js)
      touch .compiled
  pkg/%.js: js/%.js .compiled
      esbuild $< --outfile=$@
  

  这样单个JS文件更新能直接触发对应pkg文件打包，全量编译的逻辑也不受影响。

2. TSC 未正确更新目标文件时间戳 #

TSC默认会跳过内容无变化的源文件输出（哪怕是全量编译模式），如果src/a.ts的修改未被TSC正确识别（比如文件系统缓存、权限问题），会导致js/a.js的时间戳未更新：

• 修改src/a.ts后，TSC可能因缓存误判文件内容未变，未重新生成js/a.js，但你仍更新了.compiled，此时js/a.js的时间戳比pkg/a.js旧，Make不会触发打包；第二次执行Make时，TSC重新检测到文件变化，更新js/a.js的时间戳，才会触发打包。
• 调整方案：
  • 编译时添加--noEmitOnError参数，确保编译出错时不生成文件，避免半完成的编译状态。
  • 清理TSC缓存：删除tsconfig.json中配置的outDir和cacheDir（如果有），或添加--skipLibCheck --noEmit false强制TSC重新生成所有输出文件。

3. Make 并行执行打乱了时序 #

如果你的Makefile使用了-j参数开启并行执行，TSC编译和ESBuild打包可能同时运行：

• 修改src/a.ts后，Make同时触发TSC编译和ESBuild打包，ESBuild可能在js/a.js未完成更新时就读取旧文件生成pkg/a.js，随后TSC才完成编译并更新js/a.js的时间戳。此时js/a.js的时间戳比pkg/a.js新，第二次执行Make时会重新打包。
• 调整方案：
  • 禁用并行执行：执行Make时不使用-j参数，或在Makefile开头添加.NOTPARALLEL:强制串行执行。
  • 明确依赖顺序：确保pkg/%.js的依赖必须等待编译步骤完成后再执行。

4. 文件系统时间同步延迟 #

使用网络共享磁盘、Docker挂载目录等场景时，文件时间戳同步常存在延迟：

• 修改src/a.ts后，TSC生成的js/a.js时间戳未及时同步到系统，导致Make判断js/a.js的时间戳比pkg/a.js旧，第一次执行不触发打包；等时间戳同步完成后，第二次执行Make时时间戳判断正确，触发打包。
• 调整方案：
  • 避免在网络磁盘或Docker挂载目录中进行构建，改用本地磁盘。
  • 在TSC编译完成后添加短暂延迟（比如sleep 0.1）再更新.compiled文件，给时间戳同步留足时间。

内容的提问来源于stack exchange，提问作者Jeenu