LowCode Engine 源码打包排错解决 Cant import the named export from non ECMAScript module 报错【免费下载链接】lowcode-engineAn enterprise-class low-code technology stack with scale-out design / 一套面向扩展设计的企业级低代码技术体系项目地址: https://gitcode.com/GitHub_Trending/lo/lowcode-engine本文围绕 FAQ 020 中记录的报错 Cant import the named export from non ECMAScript module 展开面向需要自行构建打包lowcode-engine 源码的场景。你将理解该报错的完整成因链——源码面板插件在运行时依赖 Babel 做 JSX 编译而新版 Babel 引入的 ESM-only 传递依赖与部分打包工具不兼容——并掌握两种可落地的修复方案通过包管理器锁定 Babel 版本或在打包工具层面增加.mjs文件的处理规则。一、什么情况下会触发这个报错lowcode-engine 官方提供的是已构建好的产物绝大多数使用者直接引用 UMD/ES 产物即可。只有自己配置引擎打包流程例如基于源码二次开发、定制插件后重新构建的团队才会碰到本文的问题。为什么低代码引擎的打包链路里会牵扯到 Babel根源在于引擎的源码面板code-editor 插件它在运行时直接依赖 Babel 来完成 JSX 编译。这一点可以从仓库文档 源码面板详解 得到印证——该文档明确指出代码编辑面板允许书写 JavaScript 并支持 JSX 语法由于依赖了 Babel所以书写的 JSX 和 Chrome 80 以后的新语法也会被自动编译。也就是说Babel 不只是引擎构建期的工具它还是引擎运行时能力的一部分会被打进你的最终 bundle。因此只要你重新打包引擎Babel 及其整条传递依赖树都会成为你打包工具需要处理的模块其中任何一环存在模块格式问题都会让构建失败。二、报错根源Babel 7.17.0 引入的 ESM-only 传递依赖该报错的完整因果链如下code-editor 插件运行时依赖 Babel 做 JSX 编译见上文 源码面板详解Babel 从7.17.0版本开始其依赖树中引入了使用ESMECMAScript Module编写的ampproject/remapping2.1.0该依赖经jridgewell系列源码映射工具链间接引入 Babel 生态如果你的打包工具尤其是基于 webpack 且未对.mjs文件做类型声明的旧版本配置无法正确处理 ESM 模块就会在构建时报出Cant import the named export ... from non ECMAScript module这类错误。换句话说这不是 lowcode-engine 代码本身的问题而是Babel 生态依赖格式升级与打包工具 ESM 支持能力之间的兼容性冲突。仓库本身对 Babel 工具链的使用也很普遍例如根目录 babel.config.js 配置了babel/plugin-proposal-decorators与babel/plugin-proposal-class-propertiescode-generator 模块 的 devDependencies 中也有babel/parser、babel/traverse、babel/types等 Babel 系依赖这些都说明 Babel 版本及其依赖树的形态会直接影响整个构建体系。三、解决方案 1锁定 Babel 版本推荐用于 yarn 项目思路是让 Babel 停留在尚未引入 ESM 依赖的7.16.x版本从而在源头消除 ESM-only 依赖。如果项目使用yarn可以在你的package.json中通过resolutions字段强制锁定所有关键 Babel 包到~7.16.7resolutions: { babel/core: ~7.16.7, babel/parser: ~7.16.7, babel/preset-env: ~7.16.7, babel/preset-react: ~7.16.7, babel/standalone: ~7.16.7, babel/traverse: ~7.16.7, babel/types: ~7.16.7 }参数说明配置项取值作用babel/core~7.16.7Babel 核心锁定后其依赖树不再包含新版才引入的 ESM-only 依赖babel/parser~7.16.7语法解析器需与 core 版本保持一致避免内部 API 不匹配babel/preset-env/babel/preset-react~7.16.7预设插件包同样需要锁定防止其传递依赖拉入新版 Babelbabel/standalone~7.16.7浏览器端 Babel 运行时源码面板运行期编译的关键依赖务必锁定babel/traverse/babel/types~7.16.7AST 遍历与类型定义是 Babel 各包共享的基础包注意使用~而非精确版本号允许 7.16.x 内的补丁更新同时挡住 7.17.0 及以上版本。修改后需删除node_modules与 lockfile 重新安装确保依赖树真正收敛到 7.16.x。对于使用 npm 的项目resolutions是 yarn 专属字段可以用 npm 提供的依赖覆盖机制做等效配置具体字段名以你所用 npm 版本的实际支持为准。该方案的优点是改动集中在package.json不触碰构建配置代价是把 Babel 生态冻结在 7.16.x后续升级 Babel 时需要重新评估。四、解决方案 2打包工具层面放行.mjs文件另一种思路是不锁版本而是让打包工具正确识别 ESM 模块。webpack 对.mjs文件默认按 ESM 解析当模块实际以 CJS 方式被 require 时就会冲突将匹配.mjs的规则设置为javascript/auto后webpack 会按文件的实际import/require内容自动判定模块类型从而绕过该限制。原 FAQ 以 build-scriptsICE 团队的构建工具见 FAQbuild-scripts 的使用文档为例给出配置你可以通过其onGetWebpackConfig钩子拿到 webpack 的config对象后做等价修改module.exports ({ onGetWebpackConfig }) { // 参考 build-scripts 插件开发文档 onGetWebpackConfig((config) { config.module .rule(mjs$) .test(/\.mjs$/) .include .add(/node_modules/) .end() .type(javascript/auto); return config; }); };逐行拆解这段配置config.module.rule(mjs$)新增一条模块处理规则.test(/\.mjs$/)只匹配.mjs后缀的文件.include.add(/node_modules/)规则作用范围限定在node_modules内Babel 的 ESM 依赖正是来自node_modules不需要处理业务代码.type(javascript/auto)核心一行让 webpack 自动识别模块系统而不是强制按 ESM 解析。如果你直接裸写 webpack 而非使用 build-scripts可以在webpack.config.js中声明式地表达同样的规则module: { rules: [ { test: /\.mjs$/, include: /node_modules/, type: javascript/auto, }, ], }该方案的优点是不冻结 Babel 版本可持续跟进上游更新缺点是它依赖你的构建工具允许注入自定义 webpack 规则。五、两种方案的选型与验证维度方案 1锁定 Babel 版本方案 2配置打包工具改动位置package.jsonyarnresolutions构建配置文件build-scripts / webpack生效原理消除 ESM-only 依赖从源头规避让打包器正确解析 ESM 模块对 Babel 后续升级的影响冻结在 7.16.x升级需移除 resolutions无影响可持续使用新版 Babel适用前提项目使用 yarnnpm 需用等价的覆盖机制构建工具暴露 webpack config 定制能力验证方式应用任一方案后重新执行引擎的打包流程确认构建通过随后启动编辑器打开源码面板code-editor 插件书写一段 JSX 并确认能正常编译运行——这正好覆盖了运行时 Babel 这条能力链路其读写行为详见 源码面板详解代码在关闭面板或点击保存时写回 schema 的originCode字段解析失败会弹层提示且不会写入。小结这个报错本质是 Babel 7.17.0 起依赖树中的 ESM-only 模块ampproject/remapping与打包工具 ESM 处理能力的冲突。锁版本是快速止损的保守方案调整打包规则是面向长期的推荐方案两者都只影响你自定义的引擎打包工程不改变 lowcode-engine 引擎本身的行为。更多相关报错可参考 FAQ 索引 中错误和报错分类下的其他条目。【免费下载链接】lowcode-engineAn enterprise-class low-code technology stack with scale-out design / 一套面向扩展设计的企业级低代码技术体系项目地址: https://gitcode.com/GitHub_Trending/lo/lowcode-engine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
LowCode Engine 源码打包排错解决 Cant import the named export from non ECMAScript module 报错【免费下载链接】lowcode-engineAn enterprise-class low-code technology stack with scale-out design / 一套面向扩展设计的企业级低代码技术体系项目地址: https://gitcode.com/GitHub_Trending/lo/lowcode-engine本文围绕 FAQ 020 中记录的报错 Cant import the named export from non ECMAScript module 展开面向需要自行构建打包lowcode-engine 源码的场景。你将理解该报错的完整成因链——源码面板插件在运行时依赖 Babel 做 JSX 编译而新版 Babel 引入的 ESM-only 传递依赖与部分打包工具不兼容——并掌握两种可落地的修复方案通过包管理器锁定 Babel 版本或在打包工具层面增加.mjs文件的处理规则。一、什么情况下会触发这个报错lowcode-engine 官方提供的是已构建好的产物绝大多数使用者直接引用 UMD/ES 产物即可。只有自己配置引擎打包流程例如基于源码二次开发、定制插件后重新构建的团队才会碰到本文的问题。为什么低代码引擎的打包链路里会牵扯到 Babel根源在于引擎的源码面板code-editor 插件它在运行时直接依赖 Babel 来完成 JSX 编译。这一点可以从仓库文档 源码面板详解 得到印证——该文档明确指出代码编辑面板允许书写 JavaScript 并支持 JSX 语法由于依赖了 Babel所以书写的 JSX 和 Chrome 80 以后的新语法也会被自动编译。也就是说Babel 不只是引擎构建期的工具它还是引擎运行时能力的一部分会被打进你的最终 bundle。因此只要你重新打包引擎Babel 及其整条传递依赖树都会成为你打包工具需要处理的模块其中任何一环存在模块格式问题都会让构建失败。二、报错根源Babel 7.17.0 引入的 ESM-only 传递依赖该报错的完整因果链如下code-editor 插件运行时依赖 Babel 做 JSX 编译见上文 源码面板详解Babel 从7.17.0版本开始其依赖树中引入了使用ESMECMAScript Module编写的ampproject/remapping2.1.0该依赖经jridgewell系列源码映射工具链间接引入 Babel 生态如果你的打包工具尤其是基于 webpack 且未对.mjs文件做类型声明的旧版本配置无法正确处理 ESM 模块就会在构建时报出Cant import the named export ... from non ECMAScript module这类错误。换句话说这不是 lowcode-engine 代码本身的问题而是Babel 生态依赖格式升级与打包工具 ESM 支持能力之间的兼容性冲突。仓库本身对 Babel 工具链的使用也很普遍例如根目录 babel.config.js 配置了babel/plugin-proposal-decorators与babel/plugin-proposal-class-propertiescode-generator 模块 的 devDependencies 中也有babel/parser、babel/traverse、babel/types等 Babel 系依赖这些都说明 Babel 版本及其依赖树的形态会直接影响整个构建体系。三、解决方案 1锁定 Babel 版本推荐用于 yarn 项目思路是让 Babel 停留在尚未引入 ESM 依赖的7.16.x版本从而在源头消除 ESM-only 依赖。如果项目使用yarn可以在你的package.json中通过resolutions字段强制锁定所有关键 Babel 包到~7.16.7resolutions: { babel/core: ~7.16.7, babel/parser: ~7.16.7, babel/preset-env: ~7.16.7, babel/preset-react: ~7.16.7, babel/standalone: ~7.16.7, babel/traverse: ~7.16.7, babel/types: ~7.16.7 }参数说明配置项取值作用babel/core~7.16.7Babel 核心锁定后其依赖树不再包含新版才引入的 ESM-only 依赖babel/parser~7.16.7语法解析器需与 core 版本保持一致避免内部 API 不匹配babel/preset-env/babel/preset-react~7.16.7预设插件包同样需要锁定防止其传递依赖拉入新版 Babelbabel/standalone~7.16.7浏览器端 Babel 运行时源码面板运行期编译的关键依赖务必锁定babel/traverse/babel/types~7.16.7AST 遍历与类型定义是 Babel 各包共享的基础包注意使用~而非精确版本号允许 7.16.x 内的补丁更新同时挡住 7.17.0 及以上版本。修改后需删除node_modules与 lockfile 重新安装确保依赖树真正收敛到 7.16.x。对于使用 npm 的项目resolutions是 yarn 专属字段可以用 npm 提供的依赖覆盖机制做等效配置具体字段名以你所用 npm 版本的实际支持为准。该方案的优点是改动集中在package.json不触碰构建配置代价是把 Babel 生态冻结在 7.16.x后续升级 Babel 时需要重新评估。四、解决方案 2打包工具层面放行.mjs文件另一种思路是不锁版本而是让打包工具正确识别 ESM 模块。webpack 对.mjs文件默认按 ESM 解析当模块实际以 CJS 方式被 require 时就会冲突将匹配.mjs的规则设置为javascript/auto后webpack 会按文件的实际import/require内容自动判定模块类型从而绕过该限制。原 FAQ 以 build-scriptsICE 团队的构建工具见 FAQbuild-scripts 的使用文档为例给出配置你可以通过其onGetWebpackConfig钩子拿到 webpack 的config对象后做等价修改module.exports ({ onGetWebpackConfig }) { // 参考 build-scripts 插件开发文档 onGetWebpackConfig((config) { config.module .rule(mjs$) .test(/\.mjs$/) .include .add(/node_modules/) .end() .type(javascript/auto); return config; }); };逐行拆解这段配置config.module.rule(mjs$)新增一条模块处理规则.test(/\.mjs$/)只匹配.mjs后缀的文件.include.add(/node_modules/)规则作用范围限定在node_modules内Babel 的 ESM 依赖正是来自node_modules不需要处理业务代码.type(javascript/auto)核心一行让 webpack 自动识别模块系统而不是强制按 ESM 解析。如果你直接裸写 webpack 而非使用 build-scripts可以在webpack.config.js中声明式地表达同样的规则module: { rules: [ { test: /\.mjs$/, include: /node_modules/, type: javascript/auto, }, ], }该方案的优点是不冻结 Babel 版本可持续跟进上游更新缺点是它依赖你的构建工具允许注入自定义 webpack 规则。五、两种方案的选型与验证维度方案 1锁定 Babel 版本方案 2配置打包工具改动位置package.jsonyarnresolutions构建配置文件build-scripts / webpack生效原理消除 ESM-only 依赖从源头规避让打包器正确解析 ESM 模块对 Babel 后续升级的影响冻结在 7.16.x升级需移除 resolutions无影响可持续使用新版 Babel适用前提项目使用 yarnnpm 需用等价的覆盖机制构建工具暴露 webpack config 定制能力验证方式应用任一方案后重新执行引擎的打包流程确认构建通过随后启动编辑器打开源码面板code-editor 插件书写一段 JSX 并确认能正常编译运行——这正好覆盖了运行时 Babel 这条能力链路其读写行为详见 源码面板详解代码在关闭面板或点击保存时写回 schema 的originCode字段解析失败会弹层提示且不会写入。小结这个报错本质是 Babel 7.17.0 起依赖树中的 ESM-only 模块ampproject/remapping与打包工具 ESM 处理能力的冲突。锁版本是快速止损的保守方案调整打包规则是面向长期的推荐方案两者都只影响你自定义的引擎打包工程不改变 lowcode-engine 引擎本身的行为。更多相关报错可参考 FAQ 索引 中错误和报错分类下的其他条目。【免费下载链接】lowcode-engineAn enterprise-class low-code technology stack with scale-out design / 一套面向扩展设计的企业级低代码技术体系项目地址: https://gitcode.com/GitHub_Trending/lo/lowcode-engine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
