NestJS CLI 与 ts-node 兼容性问题解析：--enable-source-maps 标志冲突

在 NestJS 项目开发过程中，开发者可能会遇到一个典型的工具链兼容性问题：当使用 Nest CLI 结合 ts-node 运行时出现 --enable-source-maps 标志不被识别的情况。这个问题源于工具链中不同组件对 Node.js 原生功能的支持差异。

问题的本质在于，Nest CLI 自某个版本开始默认启用了 Node.js 的原生源码映射功能（通过 --enable-source-maps 标志），而 ts-node 作为 TypeScript 的直接执行环境，并不完全支持所有 Node.js 的原生命令行参数。这种工具链的不匹配导致了运行时错误。

从技术实现角度来看，Nest CLI 内部会自动添加源码映射支持以改善开发体验。源码映射对于调试非常重要，它能让开发者调试时看到原始的 TypeScript 代码而非编译后的 JavaScript。然而，当这个功能标志被传递给 ts-node 而非原生 Node.js 时，就会引发兼容性问题。

对于开发者而言，有以下几种解决方案：

1. 直接使用 ts-node：如果项目不需要 Nest CLI 提供的额外功能（如自动重建），可以完全绕过 Nest CLI，直接使用 ts-node 运行应用。这种方式最干净，但会失去一些 CLI 提供的便利功能。

2. 降级 Nest CLI 版本：回退到不自动添加源码映射标志的版本（如 v10.4.1），但这只是临时解决方案，不推荐长期使用。

3. 修改启动配置：通过调整 Nest CLI 的启动参数，避免将源码映射标志传递给 ts-node。这需要对项目配置有一定了解。

从架构设计角度看，这个问题反映了工具链设计中需要考虑的兼容性层次。理想的工具链应该能够智能识别运行时环境，并根据实际执行引擎动态调整参数。对于框架开发者而言，这也提示了在添加新功能时需要全面考虑各种使用场景。

对于大多数 NestJS 项目，最佳实践可能是：在开发环境直接使用 Nest CLI（不带 ts-node），在生产环境构建后使用 Node.js 运行。如果需要特殊预处理（如数据库种子），可以考虑将这些逻辑分离到独立的脚本中，而不是混合在主应用启动流程中。

这个案例也提醒开发者，当遇到类似工具链问题时，应该首先理清各组件的作用和相互关系，然后根据项目实际需求选择最合适的解决方案，而不是简单地回退版本或忽略错误。