我正在寻找有关我编码的模式的反馈一边修修补补。
Context
我正在为我的公司创建一个包，该包将公开发布。 DX（开发人员体验）对我们来说是最重要的，为此我选择了开发中的最新趋势：Typescript、esm 等...我想提出多个模块并使导入易于使用，类似到（例如）nextjs 的next/Router.
[EDIT]我发现关于这个线程 https://stackoverflow.com/questions/49858168/how-to-publish-typescript-modules-on-npm-without-dist-in-import并交叉引用以进行曝光。
第一步
我从一个简单的单个包、tsconfig 和 src/、tests/ 和 dist/ 文件夹开始了我的第一次尝试。那里没有什么令人难以置信的异国情调，但如果您一直这样做，您就会知道发布此内容将导致您的导入路径包含dist稍后的。
You can使用 package.json 修复此问题main字段，但这仅适用于顶级模块；你可以用exports，但它不能很好地与 Typescript 配合使用。最简单的修复方法是cp package.json dist/ && npm publish dist/，到这里，问题就解决了。
然后我想为了测试这个，我会npm link我的 dist/ 文件夹，实际上创建了“包中包”，几乎没有问题：
- the
cp package.json dist/部分会成长为有*.md，谁知道它还会增长什么/如何增长（我不想有构建脚本文件）
- 我仍然需要构建一个测试应用程序来在 DX 级别测试我的库，以及在哪里托管它？
所以我想：为什么不把它全部提升为单一仓库呢？
转折点
树结构将从：
myLib/
package.json → build + test + publish script
tsconfig.json
jest.config.json
.npmignore → managing what to distribute
...lots of config files
src/
dist/
tests/
to:
myLib/
package.json → workspaces
src-pkg/
package.json → build script
tsconfig.json → localized conf for build
dist-pkg/
package.json → publish script
test-pkg/
package.json → test script
jest.config.json → localized conf for test
传递构建的文件src-pkg to dist-pkg，我只需要指向 tsc 中的文件夹（tsc --project . --outDir ../dist-pkg)
甚至可以通过在顶层的 npm 脚本中编排工作区命令来恢复与单个包中相同的流程，例如：
{
"workspaces": ["src-pkg", "test-pkg", "dist-pkg"],
"scripts": {
"build": "yarn workspace src-pkg run build",
"test": "yarn workspace test-pkg run test",
"publish": "yarn workspace dist-pkg run publish"
}
}
后退一步
福利该结构的大部分内容都在 test-pkg 中。它可以轻松地随意测试 src-pkg 或 dist-pkg，因为这两种结构都是扁平且相似的。这样，就可以在构建之前或之后测试工作流程。
另外（这是我主要感兴趣的领域），通过位于 src-pkg 之外，test-pkg 具有我的库的使用者的 PoV（Typescript 上下文和所有） - 特别是如果使用 dist-pkg 作为依赖项 - 这样我就可以有效地提高开发人员体验，就像我是我未来的客户一样。
还有其他一些小事情，特别是使用 monorepo 进行扩展的稳定性，或者我可以在 dist-pkg 中提供单独的“公共友好”自述文件，同时在 src-pkg 清单中提供更多内部/私人详细信息。
缺点值得注意的是 semver 的管理（src-pkg 和 dist-pkg 是分开的），而且这是一个我以前从未见过的结构......感觉有点像 monorepo 结构的滥用。
所以，我已经构建了它并且它可以工作......但即使可以构建并不意味着它应该如此。
人们构建库和 SDK，你们怎么看？
感谢您的反馈意见。
