在npmmonorepo中配置package.json的最佳答案是什么（例如“main”、“module”或“exports”字段），以便本地引用的包可以在IDE和构建工具（vscode、tsx、ts-node、vite、jest、tsc等）中直接解析为它们的**.ts文件？
我不希望本地基于Typescript的任务（bundling，ts-jest testing，debugging）从dist解析到本地翻译的.js文件或解析到它们旁边的.d.ts工件。如果作者在src中编辑了一些.ts文件后没有记得重新运行构建，这些文件通常会过期。或者有一个永久的监视过程。这些任务应该直接解析为原始的.ts文件
我创建了一个引用starter monorepo，以尝试理解如何正确地指向与npm兼容的package.json（而不是pnpm**）中的Typescript源文件。This link将您带到一个示例package.json中，其中引用了同一个repo中的“@ starter/sum”，以证明vscode、tsc、vitest、jest中的本地解决方案。
在最近的这次尝试之前，我一直依赖于pnpm工具，该工具显式地允许在发布过程中覆盖package.json的本地定义的“main”字段。
在pnpm方法中，“main”在repo中被永久设置为“src/index.ts”，这在本地开发期间非常有效，并且在稍后的发布过程中，main被换出以指向“dist/index.cjs”，以使Node、CommonJS和捆绑程序满意。
我不知道是否有一种更好的方法可以用npm实现类似的功能。Npm没有publishConfig对main字段的覆盖支持。我不知道是否有一个npmpostpack步骤，我可以在其中编写对tar的更改脚本，这样我就可以在本地将我的**“main”永久设置为src/index.ts**。但在发布之前对其进行了更改，最终指向.js。
链接的参考npmmonorepo I功能正常（测试通过，存在缓存的构建任务，您可以使用sourcemapping等进行调试），但实际加载的源代码不是.ts文件，即使在monorepo中也是如此。相反，main解析为src/index.mjs，而src/index. mjs又从dist/index.js导入，dist/index.js将源代码Map回src/index.ts。因此，当后台构建尚未重新运行时，会出现一个典型的问题，即**.js文件与.ts**一起过期，因此Typescript代码更改无效。
我在https://github.com/microsoft/TypeScript/issues/51750上提出了一个相关的问题，提出了一个解决方案，但我一直在想，是否已经有一个传统的方法，我错过了，或一些技巧，人们正在使用那里。