<aside> 💡 开箱即用 x ESM = ❤️
</aside>
icejs 作为社区中流行的 React 渐进式研发框架，自身沉淀了各种面向不同业务领域多种最佳实践，但随着框架本身集成的能力越来越重，需 cover 住的场景随着框架的开源进度也越来越多。
随 vite 而在社区中大火的 ESM 开发模式，带来开发阶段调试体验的提升，在未来是能够与 webpack 所代表的 bundle 模式并驾齐驱，ESM 的标准化和社区生态也会在未来逐步完善，越来越多的技术方案可以基于 ESM 进行建设，而当一个框架在启动时能像打开一个网页一样快的时候，那说明我们已经从能力上的开箱即用，迈进到了框架整体上的开箱即用。
对于上层应用框架而言有必要探索下一代基于 Native ESM 在整个体系中的应用场景。而 ice x vite 将作为 ice 的新鲜血液，抛下重负，面向未来，重新出发。
本文主要揭示这几个月来 ice 团队在 ESM 方案的开发上做的一些探索与开发，中间涉及到技术选型与方案落地的一些细节。
一开始，我们基于 vite 搞出来了 ice-lite，它独立于 icejs，对于前端开发者来讲，这又是一个全新的框架，可是我们的前端开发者每天需要接触这么多的框架，突然手上又多了一个框架要去了解，这样真的好吗？
所以后来，我们在想一件事，好像是不是可以存在一个按钮或者配置，让我们的开发者可以直接在配置文件里，像这样，一键去让自己的项目去支持 ESM 这种面向未来的开发方式呢？
而现在，这种方式已经成为了现实。我们找到了开箱即用与快速开发之间的平衡，全面提升了开发者的幸福感。
其实，在当初我们的直觉告诉我们，集成 ESM 开发模式的难度不亚于把 ice 重写一遍，这样就意味着要把 ice 的内置插件与周边的插件全部舍弃，这样的成本是巨大的，所以我们从尽可能减少存量 build-plugin 插件维护的成本这个条件出发：
由于 Webpack 与 Vite 基本作为现代的 Web 应用构建器，两者基本能力存在一致性，所以考虑开发能够统一将 webpack / ice 配置的转换器 ，通过转换器把存量配置转换为 vite 的基础配置或基于 rollup 底层能力的插件。
这样的话，我们的问题就从「如何让 ice 支持 ESM 开发模式」转移到了两个开发模式配置的兼容问题。