2

我最近使用可加载组件实现了带有代码拆分的服务器端渲染反应应用程序

但似乎 loadable-components 本身依赖于 webpack，因为 loadable 用自己的报告器替换了 jsonp_callback。

那么在使用其他打包工具（如 rollup、esbuild）时，我们可以使用哪些替代选项？

我们是否必须手动遍历反应树以预先配置哪个组件需要哪个块，除非在服务器端渲染上实现代码拆分时没有特定的捆绑器目标库（如可加载组件）？

4

1 回答 1

1

tsconfig typeRoots 是不必要的吗？

首先，让我们查阅编译器选项参考：

国家的文件 typeRoots（强调我的）：

默认情况下，所有可见@types的包都包含在您的编译中。任何封闭文件夹中的包node_modules/@types都被认为是可见的。例如，这意味着./node_modules/@types/、../node_modules/@types/、../../node_modules/@types/等中的包。

如果typeRoots指定，则仅包含以下包typeRoots。

第二行很重要：如果您未设置，则 tsc 默认会在其目录名称中包含typeRoots的目录下查找目录。node_modules@types

（文档并没有说明它是否node_modules因为moduleResolution参数而选择。（我怀疑我需要深入研究tsc的源代码才能确定）。）

如果您确实设置了一个值，则该值typeRoots会覆盖 tsc 的node_modules/**/@types*查找逻辑，然后它将仅在指定的目录中查找。

据我所知，我必须将上述文件的路径指定为 filetypeRoots选项，tsconfig因为typeRoots默认情况下会查看node_modules/@types.

不必要。您还可以将额外的类型文件的位置添加到paths参数中并将typeRoots参数留空/未设置，这意味着tsc将保留“ node_modules/@types-and-ancestor-walking 行为”，但会.d.ts很好地看到您的文件。

此 TypeScript GitHub 线程中提到了此场景：https ://github.com/microsoft/TypeScript/issues/13581

因此，如果您要询问您机器上特定的本地环境：并假设您坚持使用规范的、典型的（我敢说是主流的）TypeScript 工作习惯用法（例如 using npm），那么是的：您可以删除typeRoots参数，因为tsc的（当前）默认行为是node_modules在与tsconfig.json.

（我知道 VS Code 也可能会在幕后拉一些字符串以tsc“了解”您的项目文件和依赖项以及它的语言服务器进程 - 但这并不重要，因为您会注意到tsc应该以相同的方式工作从 VS Code 之外的命令行）。

如果您询问typeRoots编译器选项的基本必要性，并假设您在想“因为实际上每个人都在使用npm，node_modules那么为什么 TypeScript 团队要花时间支持不寻常的开发配置？”_ - 对许多人来说很好的理由：工具不应该依赖于第三方控制的其他工具1：考虑npm生态系统和/或 NodeJS 软件可能在一夜之间过时的可能性，然后我们会被tsc's 默认值卡住仍然使用node_modules当每个人都在玩一些新的很酷的 JS 环境时：解决这个烂摊子会让人头疼很多年（并不是说 JS 生态系统不是一团糟）。

并且有很多不使用npmand的充分理由node_modules：人们可能在没有互联网访问的环境中使用 TypeScript（想想：安全软件开发、国防工业、国家机密等）——在这些情况下，那些人可能拥有完整的网络共享不会使用node_modules's 命名约定的已批准或已知值得信赖的库 - 在这种情况下，如果这些人想要使用d.ts文件，他们将需要typeRoots为自己手动配置参数。

1我知道npm（在法律上与 NodeJS 是分开的，顺便说一句）由npm Inc维护，它是 Microsoft 的子公司（通过被 GitHub 收购，也是 Microsoft 的财产），因此不应该tsc依赖是个问题——但这是最近发生的事情：微软在 18 个月前的 2020 年 3 月才被收购——微软很可能会分拆npm Inc——或者让它陷入困境，然后每个人都切换到. 因此，无论当前流行的任何工具的最终合法所有者如何，您都不想要这样的不必要的依赖关系。npm npmyarn

于 2021-10-18T05:13:11.413 回答