JavaScript模块化处理历史遗留插件的核心是“桥接封装”而非改写源码，通过包装层实现ESM兼容；按全局变量型、IIFE型、UMD型三类分别封装，并在浏览器、Node.js及打包工具中采用对应策略确保平滑过渡。
JavaScript模块化处理历史遗留非模块化插件，核心思路不是“强行改写”，而是“桥接封装”——在不修改原插件源码的前提下，通过包装层使其具备模块行为，实现与现代ES模块（ESM）环境的兼容。
识别插件类型并选择封装策略
非模块化插件通常有三类典型形态，对应不同封装方式：
-
全局变量型：如
jQuery、Swiper插件直接挂载到window上（window.Swiper）。封装时需在模块中手动检测全局对象，并用export default或命名导出暴露。 - IIFE立即执行函数型：常见于老版UI组件（如某些弹窗库），返回一个对象或构造函数但未赋值给全局。可将其包裹为 IIFE 调用后导出结果。
- UMD格式（但未启用模块环境）：这类脚本本身支持 AMD/CommonJS/全局三种模式，但在浏览器 ESM 环境下未自动触发模块分支。需手动调用其 UMD 工厂函数并导出。
浏览器中封装全局插件为ES模块
以 jQuery 为例（假设已通过 <script src="jquery.min.js"></script> 加载）：
// jquery-wrapper.js
// 不要写 export default $ —— 因为 $ 可能尚未就绪
// 正确做法：显式检查 window.jQuery，再导出
if (typeof window.jQuery === 'undefined') {
throw new Error('jQuery is not loaded. Please include jquery.min.js before this module.');
}
export default window.jQuery;
export const $ = window.jQuery;
然后在主模块中使用：
立即学习“Java免费学习笔记（深入）”；
import $, { $ as jq } from './jquery-wrapper.js';
console.log($.fn.jquery); // 正常输出版本号
Node.js中加载无模块声明的老脚本
在启用 "type": "module" 的 Node.js 项目中，无法直接 import 传统脚本。可行方案包括：
-
用
import()动态加载 + 手动提取：适用于只执行一次、副作用即生效的插件（如样式注入、全局补丁）。 -
通过
vm.SourceTextModule沙箱执行（高级用法）：将脚本内容读取为字符串，在模块上下文中运行，再从context中取值导出。 -
降级到 CommonJS 子进程或子模块：新建
.cjs文件，用require()加载老插件，再用export default包装导出（需注意 ESM 不能require，但 CJS 可importESM；因此可建中间层）。
打包工具中的平滑过渡方案
若使用 Vite、Webpack 或 esbuild，推荐借助配置而非代码封装：
- Vite：在
vite.config.js中用optimizeDeps.include将老插件列入预构建，或用resolve.alias映射路径到包装模块。 - Webpack：通过
externals声明全局依赖（如jquery: 'jQuery'），再配合ProvidePlugin自动注入$和jQuery到每个模块作用域。 - esbuild：用
plugins拦截对老插件路径的 import 请求，返回自定义导出代码字符串。
本质上，封装不是为了消灭历史代码，而是建立一层语义清晰、行为可控的接口。只要导出符合 ESM 规范、导入路径可解析、执行时机可控，老插件就能自然融入现代模块流。
