JS
一、认识
JS Entry 的方式通常是子应用将资源打成一个 entry script，要求子应用的所有资源打包到一个 js bundle 里，包括 css、图片等资源。
Single-Spa 通常是结合SystemJS来实现，在single-spa框架中，基座会检测浏览器url的变化，在变化时往往通过SystemJS的import映射，来加载不同的子应用js。
Single-Spa 做了两件事情:
-
加载微应用（加载方法还得用户自己来实现）
-
管理微应用的状态（初始化、挂载、卸载）
而 JS Entry 的理念就在加载微应用的时候用到了: 在使用 single-spa 加载微应用时，我们加载的不是微应用本身，而是微应用导出的 JS 文件，而在入口文件中会导出一个对象，这个对象上有 bootstrap、mount、unmount 这三个接入 single-spa 框架必须提供的生命周期方法，其中 mount 方法规定了微应用应该怎么挂载到主应用提供的容器节点上，当然你要接入一个微应用，就需要对微应用进行一系列的改造，然而 JS Entry 的问题就出在这儿，改造时对微应用的侵入行太强，而且和主应用的耦合性太强。
Single-Spa 采用 JS Entry 的方式接入微应用。微应用改造一般分为三步:
-
微应用路由改造，添加一个特定的前缀
-
微应用入口改造，挂载点变更和生命周期函数导出
-
打包工具配置更改
侵入型强其实说的就是第三点，更改打包工具的配置，使用 single-spa 接入微应用需要将微应用整个打包成一个 JS 文件，发布到静态资源服务器，然后在主应用中配置该 JS 文件的地址告诉 single-spa 去这个地址加载微应用。
不说其它的，就现在这个改动就存在很大的问题，将整个微应用打包成一个 JS 文件，常见的打包优化基本上都没了，比如: 按需加载、首屏资源加载优化、css 独立打包等优化措施。
二、特点
2.1 优点
2.2 缺点
-
子应用更新打包后的
js bundle名称会变化，主应用需要保证每次获取 都是最新的js bundle子应用所有资源打包到一个文件中 -
会失去
css提取、静态资源并行加载、首屏加载(体积巨大)等优化 -
需要在子应用打包过程中，修改相应的配置以补全子应用
js资源的路径