我报名参与金石计划1期应战——瓜分10万奖池，这是我的第1篇文章，点击检查活动详情
hel-micro，模块联邦sdk化，免构建、热更新、东西链无关的微模块计划 ，欢迎注重与了解
| 示例称号/功用 | 运用示范 | 模板地址 | 模板描绘 | 托管方位 |
|---|---|---|---|---|
| 长途ts库 | codesandbox | hel-lodash | webpack开发与打包 | unpkg meta |
| 长途 react js 组件 | codesandbox | remote-react-comp | webpack开发与打包 | unpkg meta |
| 长途 react ts 组件 | codesandbox | remote-react-comp-ts | webpack开发与打包 | unpkg meta |
| 长途 vue2 js 组件 | codesandbox | remote-vue-comp | webpack开发与打包 | unpkg meta、github.io index.html 、unpkg index.html |
| 长途 vue3 ts 组件 | codesandbox | remote-vue3-comps-ts | vite 或 webpack开发，webpack打包 | unpkg meta |
模块联邦之缘起
自谷歌chrome浏览器异军突起，并在2008年9月2号 正式官宣发布 v8 js引擎之后，它以极高的运转功率席卷了网络世界，一起也捕获了很多用户，这种不行阻挠的势头让其他各大科技公司（apple、moliza、microsoft）感受到了巨大的杀气， 随即咱们都开端招兵买马、磨刀赫赫准备杀出一条血路，从此js引擎进入了军备竞赛时期，这其中微软甚至不吝自废IE并开端力推背后携带了微软很多汗水的全新js引擎 Chakra的edge浏览器，可想而知咱们对js引擎这块蛋糕的注重程度有多高，而v8的诞生催化了很多的闻名开源著作，让js生态一向保持着十分微弱的活力，这其中最闻名的便是 2009 年诞生的nodejs，一个根据v8的服务端js运转时，让js这门语言开端从前台到后台遍地生花，以至于以下一句很早诞生的戏弄言语至今还在撒播：
Any application that can be written in JavaScript, willeventually be written in JavaScript.
模块化标准
nodejs将commonjs模块化带到了服务器端，让大型js工程组织起来更加有条有理，一起也带了npm这个超级杀手锏，让模块分发与同享功率进步到了史无前例的高度。
而前端运用也随着网络运用的杂乱度成倍进步，导致进入代码体积进入了高速胀大时期，这个时候急需一个有效的模块化计划来处理怎么高雅拆分模块，怎么进步代码复用性和可维护性等一系列问题。
此刻两大主流模块化计划amd和cmd开端在前端这里竞相角逐并最终各自站稳了一份很大的地盘，他们的代表完成分别是requirejs和seajs，信任不少小伙伴都了解或运用过。
工程化系统
尽管requirejs和seajs为前端带来了模块化标准的完成并给大型js工程注入了安定的根基，但是仅靠模块化标准，仍然不能处理怎么和npm生态互通，怎么管理日趋杂乱的模块依托联系，假如兼容新的js特性等一系列问题，归根到底，这里面涉及到一个要害词工程化系统，之后webpack和babel便诞生了，他们方针十分清晰，处理了以下图中的4大问题
随即成为了前端开端工程化系统开发的事实上的基建标配。
webpack依托优异的插件和加载器机制，让其环绕它的生态得以不停地做大做强，干掉了进程其他更倾向于东西的gulp，grunt等一众对手
npm 的魔咒
webpack和npm几乎形成了完美伙伴的状态，但前端本来从cdn获取的资源改由打包东西合并到一个包体里带来了丧命的更新和布置功率问题。
在某些需求需求动态更新的场景，这种all in one的打包机制让包体的布置功率大打折扣，这本不是webpack和npm的问题，而是人们天然生成对web环境需求快速迭代、快递试验的高要求带来的典型场景需求。
注：externals 自身不能彻底处理动态更新的诉求，只适合于将底层公关依托包体外链到cdn
bundless 来袭
一起webpack随着项目体积日趋巨大，新的问题比如开发体会差（热更新慢）、包体加大、构建速度慢（node_modules黑洞）等问题也诞生了，此刻新生代的开发东西snow和vite以不打包的名义开端蚕食webpack的市场。
他们都利用了浏览器的原生模块化才干esm，越过webpack的需求的依托剖析和打包流程，在此规划下做到了毫秒级的调试启动。
但它们带来的极致快体会并不能动摇整个webpack生态的深沉围城，事实上咱们都是处于调试根据vite而生产打包还是用webpack的双擎驱动模式，究竟esm遍及还需求时间。
模块联邦吹响反攻号角
已然咱们都吐槽wepack构建慢，那么可不行以有一种方法既能越过构建过程又能让用户能够按自己的方法组合多层次依托模块呢？
当然有的，那便是走预构建这条路途
模块联邦因此诞生了，它的伟大之处在于保持当前前端开发模块化、组件化、工程化的高功率系统下，答应模块独立开发、独立布置，经过 CDN 直接同享，然后挣脱npm包体无法动态更新的枷锁，然后推进整个前端界开发和运转体会上升到一个新高度。
只需有越多的模块能进步到联邦里，本地启动速度将越快！
而且联邦模块天然生成具有双重身份，即能够是模块顾客，也能够是模块供给者，这让模块联邦运用之间形成了天然的网格联系，模块分发功率、布置功率、同享功率都得到了史无前例的进步！
模块联邦的阿喀琉斯之踵
webpack 5或许其他东西带来的模块联邦完成真的完美了吗？它确实处理了免构建、动态更新、跨项目同享模块的问题
但根据现有的编译时插件化机制去完成，无法躲避东西链强绑定，编译时确定才干长途模块消费联系的难题
试想一下，你需求运用模块联邦这么技能，需求做的前置条件有多重，需求升级整个东西链！而且不同东西链之前的联邦模块是互相不通的！模块的流通性绑定在了你选择的东西链上。
模块联邦新体会
破除这两大难题的仅有解便是将其sdk化，这是hel-micro对模块联邦完成的全新考虑，也是建议模块联邦新体会的秘密武器。
sdk化后，任何技能栈、任何东西链均可无损、无痛接入模块联邦技能。
运转时的模块消费联系
从东西链回归到js语言自身，意味着模块消费联系从编译时进步到运转时，将极大进步动态载入长途模块的灵敏性，为更杂乱的业务赋能。
降维打击
对比依托东西插件完成的模块联邦，hel-micro从语言层面的完成将对其他模块联邦完成造成降维打击。
相比传统的npm同享方法，hel-micro也具有更高效的代码同享才干（运转时同享）
解密 sdk 化中心完成
要完成sdk化，意味着咱们必须挖掘出js语言自身的隐含才干，并跳出传统的打包流程思想，才干达到咱们的最终方针
异步import隐藏的才干
一般咱们都会在头文件运用import要害字静态导入其他模块，但其实import能够作为函数调用，异步的导入一个模块，并回来一个promise目标
const mod = await import('./some-mod');
所以咱们能够经过微调模块的加载顺序，来达到为一个模块被其他模块静态导入之前能够为它注入新代码的效果
而这个异步import带来的提早注入效果成为了hel-micro为模块署理目标注入长途运转时代码的要害完成点，让hel-micro能够位用户供给懒加载和预加载两种加载方法。
上图里两个中心接口：libReady接口担任暴露模块，preFetchLib接口担任拉取模块，经过调用接口的行为让每一个模块都表现为供给方或许顾客。
运转时依托剖析
hel-micro经过内部维护的事件总线、模块池、样式池、元数据池四个数据结构，让有多级依托层次的长途模块得以高效并安全有序的加载。
其中模块池能保证模块不被重复加载并被上层各方调用者重复运用。
元数据-模块的灵魂
模块的实质是构建产物文件的调集，hel-micro经过供给构建时的插件，搜集好产物的网络路径并按sdk规定的协议存储起来，得以后续能够在网络让sdk能够下载并执行所有的长途模块。
双构建机制
hel-micro运用rollup打包本地可静态导入的署理文件，运用webpack打包长途注入的实践运转代码，来达到能够本地静态导入node_modules里的署理模块目标得到完好的类型提示，让用户能得到像运用本地模块相同地运用长途模块的极致开发体会
内定了4个目录hel_dist，hel_proxy，hel_proxy_es，hel_bundle来承载不同的产物，供package.json配置不同的入口。
其中hel_proxy，hel_proxy_es目录下的文件是便是咱们提到的模块署理目标的入口文件，咱们能够看到该文件近乎一个空壳，所以它对模块运用方的打包体积巨细影响几乎能够省略不计。
渠道与生态
hel-mirco sdk首要依托标准化的元数据格式来做长途模块加载，所以只需恣意用户按照标准格式供给模块的元数据，即可被hel-micro加载，这将极有利于环绕hel-micro的上层生态的建造与开展。
支撑模块恣意布置
sdk与渠道是解耦的，咱们默认供给了和hel pack与npm unpkg的支撑，但答应你能够将模块发布到网络上的恣意文件服务，仅需知道其布置地址即可。
如用户将 hel-meta.json 元数据保存到后台数据库（可结合devops流水线），就可很快搭出一个相似hel pack的中心化的模块管控渠道
中心化的模块管控渠道对模块实施版别预览、灰度放量、秒级回滚等工作会特别方便，但它不阻碍sdk以去中心化的方法加载多渠道包体，因为sdk天然生成支撑一起从多个不同的渠道拉取长途模块并运用，例如一起加载来自unpkg 和 hel pack2个渠道的模块，渠道值会被作为命名空间来阻隔不同渠道或许重名的模块。
上层生态建造
hel-micro自身只供给长途模块加载的才干，具体的ui适配层还需求上层封装库区完成，目前的规划如下图
以 hel-micro-react为例，供给以react钩子函数的方式懒加载长途组件，并一起供给shadow dom样式阻隔功用
微前端架构考虑
这些年来咱们提到微前端，几乎把该架构和技能栈无关、独立布置、js css运转阻隔这3大特性画起了等号，但其实这些特性在针对以下比如兼容前史留传项目运转、跨部门合作等场景时才需求，此刻咱们可依托于微容器计划（原生iframe、乾坤、micro-app、无界等）做微前端架构，但假如咱们收敛到单一技能栈系统下来做，其实只需求满足模块独立布置、运转时组合、css阻隔这几个特性的话，微模块计划（模块联邦）才是正确的架构完成，它更轻量且更灵敏。
当然了两者并非水火不容，它们搭配起来混合运用将是相辅相成的完美组合，你能够先运用微容器再接入微模块做跨运用模块动态同享，或先运用微模块再套上微容器做运转时阻隔，取决于你的项目开展到了什么阶段（是否需求多技能栈混合开发，是否需求多版别技能栈一起迭代等）。
例如下图无界和hel-micro混合运用的事例，能够看到多个技能栈的容器里再次以模块的粒度来动态组合运转时代码的效果演示。
何时采用hel-micro
当前时间当你遇到以下恣意一种情形时，采用hel-micro都绝对值得你投入去测验。
npm私服可经过
verdaccio建立，版别化的cdn包管理可经过unpkg私服来做。
roadmap 2022~2023
3闪电表示已经安排妥当，2闪电表示快要完成
结语
模块联邦关于建立超大型js工程能到如虎添翼的效果，巨型运用的模块布置功率、同享功率都将方便的解决，一起搭配微容器相关框架（如wujie、rame）等，为你的阻隔运转需求保驾护航，欢迎 star hel-micro，了解并运用。
我的其他开源著作友链（欢迎注重与了解）：
concent，一个自带依托搜集、供给setup特性的react数据流计划
limu，一个比immer更高效的js不行变操作库
