我正在编写一个库，它公开了一些React组件作为其API的一部分。
我将在这里做一些假设：
1-它将在react项目中使用。
2-这些项目将在某个时候捆绑它们的依赖项。
3-那些react项目可以使用JSX作为描述UI的一种方式。
4-他们选择的捆绑器Webpack(如果它是一个创建-反应应用程序(将使用babel来解析JSX并将其转换为普通JS。
根据该逻辑，I应该能够从外部包导出一些JSX，因为包的代码将与应用程序一起捆绑、传输。
然而，当我在创建反应应用程序项目中这样做时，我会得到以下错误：
SyntaxError:/Users/someone/Desktop/someproject/dist/esm/index.js:当前未启用对实验语法"jsx"的支持(35:13(：
添加@babel/preset-react(https://git.io/JfeDR)到Babel配置的"预设"部分，以启用转换。如果您想保持原样，请添加@babel/plugin-syntax-jsx(https://git.io/vb4yA)到"plugins"部分以启用解析。
是的，我可以转换JSX，也许我会的。我只是看不出有什么理由，如果它无论如何都要捆绑在一起的话。我更喜欢把运输调整和优化留给用户。
我担心的是，如果我自己移植，我有两个选择。
在scope中导入React，并使用babel将
<MyComponent/>转换为React.createElement()，但这将排除使用新的JSX转换的可能性
自己使用新的JSX转换，并确定我的代码是否与17之前的react版本兼容。并增加我自己的捆绑包大小，因为babel添加了很多代码来实现这一点。
在这一点上，我想我对这个问题很兴奋，因为坦率地说，我不知道为什么我不能从我的包中导出纯JSX。我知道我可能遗漏了一些明显的东西，比如分号或其他什么，但我真的很想理解。
如果您想要一些代码/汇总-babel配置，请随时询问。
坦克！
乍一看，您的逻辑似乎很有意义。但让我们来看看为什么这是个坏主意。
JSX是一种特殊的语法，必须转换到最低通用的demonator才能在浏览器或Nodejs中理解。这就是bundler所做的，正如您所提到的，在节点环境中使用react的任何人几乎都可以肯定地使用bundler来实现这一点。
然而，人们可以在代码中使用任意数量的wierd语法。当bundler从node_module导入代码时，如果这些模块中的代码尚未被转换，则bundler还需要将它们转换为。考虑到未编译的模块可能有任何数量的奇怪语法，每个模块都需要自己的编译指令(想想babel配置(。为每个node_module提供唯一的转换配置将非常困难，更不用说必须以不同的方式对每个node_mode进行转换，这可能会对性能不利。
解决这个问题的公认最佳实践是简单地使用捆绑器构建包，该捆绑器将代码归结为最低公分母。这使得您的包用户的bundler只需在node_module中引入代码即可；照原样"；。
虽然可能会想出一些疯狂的babe/webpack/rollup指令来将你的模块自定义为JSX，但你真的希望你的库用户必须这样做吗？特别是在使用create-rect应用程序的情况下，CRA的babel配置本机不支持自定义，这意味着他们需要采取额外步骤才能让您的库正常工作。此外，由于明显的性能原因，webpack默认将node_modules从js转换中排除，CRA遵循此约定。在发布库时，您希望它们尽可能容易地被普遍使用。
代码的移植、调整和优化最好留给编写人员，在您试图发布的react组件库的情况下，就是您自己。