hel-micro，模块联邦基于sdk，免构建，热更新，独立于工具链的微模块解决方案，欢迎关注了解模块联邦的由来从Googlechrome浏览器的异军突起，到2008年9月2日v8js引擎正式发布后，以极高的运行效率席卷了互联网世界，俘获了大量用户。这种势不可挡的势头，让其他各大科技公司（apple、moliza、microsoft）都感受到了巨大的杀机，随之大家都开始招兵买马，磨刀霍霍，准备杀出一条血路。从此，js引擎进入了军备竞赛期。Chakra的edge浏览器，一个全新的煞费苦心的js引擎，可想而知大家对js引擎这块蛋糕是多么的重视，而v8的诞生催生了一大批著名的开源作品，让js生态保持了下来非常强壮。活力，其中最出名的就是诞生于2009年的nodejs，一个基于v8的服务端js运行时，让js语言从前台到后台蓬勃发展，以至于下面诞生很早的调侃是今天还活着传播：任何可以用JavaScript编写的应用程序，最终都将用JavaScript编写。模块化规范nodejs将commonjs模块化带到了服务端，让大型js项目组织起来更加有序，同时也带来了npm这个超级大杀器，让模块的分发和共享效率提升到了前所未有的高度。前端应用也随着网络应用的复杂度成倍增长，导致一段代码量快速膨胀的时期。这时候就急需一种有效的模块化方案来解决如何优雅地拆分模块，如何提高代码的复用性和可用性。可维护性等一系列问题。这时，AMD和CMD两大主流模块化方案开始在前端展开角逐，并最终大放异彩。他们的代表实现分别是requirejs和seajs。相信很多小伙伴都知道或者用过。.工程系统虽然requirejs和seajs已经将模块化规范的实现带到了前端，为大型js项目注入了坚实的基础，但是单靠模块化规范仍然无法解决如何与npm生态沟通，如何管理越来越复杂的模块依赖，如果是兼容js新特性等一系列问题，归根结底还是涉及关键字工程系统，于是webpack和babel就诞生了。他们的目标很明确，解决了下图中的四大问题。它已经成为前端工程系统开发事实上的基础设施标准。依靠webpack优秀的插件和loader机制，围绕它的生态可以不断做大做强，干掉gulp、grunt等其他更工具化的对手。npm的魔咒webpack和npm几乎已经形成了完美搭档的状态，但是原本前端从CDN获取的资源被打包工具合并成了一个包体，带来了致命的更新和部署效率问题。在一些需要动态更新的场景下，这种一体化的打包机制大大降低了包体的部署效率。这不是webpack和npm的问题，而是人们自然需要对web环境的快速迭代和快速实验。高要求带来的典型场景需求。注意：externals本身并不能完全解决动态更新的需求。只适合做底层公关包外链cdnbundless。同时，随着webpack的项目体量越来越大，开发体验差（热更新慢）、包体体积增大、构建速度慢（node\_modules黑洞）等新问题也诞生了.这时，新一代的开发工具snow和vite开始以不打包的名义蚕食webpack市场。它们都利用了浏览器原生的模块化能力esm，跳过了webpack需要的依赖分析和打包过程，在这种设计下实现了毫秒级的调试和启动。但它们带来的极速体验，无法撼动整个webpack生态的深重围攻。其实大家都是基于vite调试和生产打包或者使用webpack的双引擎驱动模式。毕竟esm要普及还需要时间。模块联合会吹响逆袭的号角既然大家都在抱怨wepack构建慢，那么有没有办法跳过构建这一步，让用户按照自己的方式组合多级依赖的模块呢？当然有，那就是走预建之路，于是诞生了模块联邦。它的伟大之处在于保持了目前前端开发模块化、组件化、工程化的高效体系，允许模块独立开发、独立部署，通过CDN直接共享，从而摆脱npm包体的束缚不能动态更新，从而推动整个前端行业的开发和操作体验上一个新台阶。只要能提升到联邦的模块越多，本地的启动速度就会越快！而且，联邦模块具有双重身份，既可以是模块消费者，也可以是模块提供者，使得模块联邦应用之间形成天然的网格关系，模块分发效率、部署效率、共享效率都达到了前所未有的水平.升级！modulefederation的致命弱点，webpack5或者其他工具带来的modulefederation真的完美吗？确实解决了模块免构建、动态更新、跨项目共享等问题，但是基于现有的编译时插件机制，无法避免工具链的强绑定，以及远程的问题模块消耗关系只能在编译时确定。试想一下，你需要使用模块联邦的技术，需要做多个前置条件，需要升级整个工具链！而且不同工具链之前的federation模块互不兼容！模块流动性与您选择的工具链相关。模块联盟的新革命要破解这两个问题，唯一的解决办法就是让其SDK化。这是hel-micro对模块联合体实现的新思考，也是开启模块联合体新革命的秘密武器。SDK化后，任何技术栈、任何工具链都可以无损无痛地接入模块联邦技术。运行时模块消费关系从工具链回归到js语言本身，意味着模块消费关系从编译时升级到运行时，将大大提高动态加载远程模块的灵活性，赋能更复杂的业务。与依赖工具插件实现的模块联邦相比，hel-micro从语言层面的实现会对其他模块联邦的实现造成降维打击。相较于传统的npm分享方式，hel-micro还有更高效的代码分享能力（runtimesharing）来解密基于sdk的核心实现。实现sdk-based，意味着我们必须挖掘出js语言本身隐藏的能力，而跳出传统的打包流程思维才能达到我们最终的目的异步导入的隐藏能力通常我们在头文件静态导入其他模块，但实际上import可以作为函数调用异步导入模块并返回一个promise对象constmod=awaitimport('./some-mod');所以我们可以微调模块的加载顺序，达到在一个模块被其他模块静态导入之前注入新代码的效果，而这种异步import带来的提前注入效果成为hel-的关键实现点micro将远程运行时代码注入到模块代理对象中，这样hel-micro就可以为用户提供两种加载方式：延迟加载和预加载。上图中有两个核心接口：libReady接口负责暴露模块，preFetchLib接口负责拉取模块。通过调用接口，每个模块充当提供者或消费者。运行时依赖分析hel-micro通过内部维护的事件总线、模块池、样式池、元数据池四种数据结构，让具有多级依赖的远程模块高效、安全、有序地加载。其中，模块池可以保证模块不被重复加载，被上层各方调用者复用。元数据——模块的灵魂模块的本质是构建产品文件的集合。Hel-micro在构建时通过提供插件，收集产品的网络路径，并按照SDK规定的协议进行存储，以便后期在网络上下载SDK并执行所有远程模块。双重构建机制hel-micro使用rollup将本地可以静态导入的代理文件进行打包，使用webpack将实际运行的代码进行打包进行远程注入，这样就可以在本地静态导入node_modules中的代理模块对象来完成类型提示，让用户获得像使用本地模块一样使用远程模块的极致开发体验。hel_dist、hel_proxy、hel_proxy_es、hel_bundle四个目录默认携带不同的product，package.json配置不同的入口。其中hel_proxy和hel_proxy_es目录下的文件就是我们提到的模块代理对象的入口文件。我们可以看到该文件几乎是一个空壳，因此它对模块用户包大小的影响几乎可以忽略不计。平台与生态hel-mircosdk主要依赖标准化的元数据格式进行远程模块加载，因此任何用户只要按照标准化格式提供模块的元数据，就可以被hel-micro加载，这将是非常有利于hel-micro上层生态的建设和发展。支持模块任意部署sdk与平台解耦。我们默认提供对helpack和npmunpkg的支持，但允许您将模块发布到网络上的任何文件服务，您只需要知道它的部署地址即可。如果用户将hel-meta.json元数据保存到后台数据库中（可以结合devopspipeline），可以快速搭建类似helpack的集中式模块管控平台。模块集中管控平台对模块实现版本预览，灰度化和秒级回滚特别方便，但不妨碍SDK中立加载多平台包，因为SDK自然支持同时从多个不同平台拉取和使用远程模块。例如，如果同时加载来自两个平台的模块，unpkg和helpack，平台值将用作命名空间，以隔离在不同平台上可能具有相同名称的模块。上层生态构建hel-micro本身只提供加载远程模块的能力。具体的ui适配层也需要在上层封装库区实现。目前的计划如下。以hel-micro-react为例，以reacthook函数的形式提供远程组件的懒加载，同时提供shadowdom风格的隔离功能什么时候使用hel-micro当前时刻当你遇到任何以下情况，使用hel-micro绝对值得您的投资。roadmap2022~2023EpilogueModulefederation在构建超大型js项目中可以发挥更强大的作用，解决巨型应用的模块部署和共享效率问题。为运营需求保驾护航，欢迎starhel-micro，了解并使用。_我的另一个开源作品朋友链接（欢迎关注和理解）：concent，一个自带依赖收集和设置特性的react数据流解决方案limu，一个比immer更高效的js不可变操作库
