Ignite项目中Expo CNG工作流的原生文件夹生成问题解析

背景介绍

在使用Ignite框架创建React Native应用时，开发者选择Expo CNG(Configurable Native Generation)工作流时遇到了一个预期与实际行为不符的情况。根据文档描述，选择CNG工作流不应生成原生iOS和Android文件夹，但实际上却生成了这些文件夹，并且运行开发构建时出现了兼容性问题。

问题本质

这个现象实际上不是bug，而是Ignite框架在版本10中的设计决策。Ignite团队为了提升开发体验，在CNG工作流中默认生成了原生文件夹，但将这些文件夹添加到了.gitignore中。这样做的目的是：

1. 允许开发者在本地直接运行构建，而不必一开始就构建开发客户端
2. 保持项目整洁，避免将生成的原生代码提交到版本控制
3. 为开发者提供更灵活的选项，可以根据需要选择工作流

技术细节解析

在Ignite 10版本中，框架不再默认支持Expo Go，这是为了能够集成更多原生功能模块，如MMKV(高性能键值存储)和键盘控制器等。这些模块无法在标准的Expo Go环境中运行，因此需要以下两种方式之一：

1. 使用EAS(Expo Application Services)预构建
2. 完全弹出(eject)到裸工作流(bare workflow)

解决方案

对于仍希望使用Expo Go的开发者，可以采取以下方法：

1. 移除原生文件夹：直接删除生成的ios和android文件夹不会影响项目功能

2. 构建开发客户端：通过Expo的dev client功能来获得与Expo Go类似的体验

3. 降级使用Ignite 9.x版本：最后一个支持Expo Go开箱即用的版本

4. 替换不兼容的依赖：

   • 将MMKV替换为react-native-community的async storage
   • 重写Screen组件，使用React Native核心的KeyboardAvoidingView替代自定义键盘控制器

最佳实践建议

1. 评估项目需求：如果需要使用Expo Go，建议在项目初期就做好技术选型

2. 理解工作流差异：CNG工作流提供了更大的灵活性，但也带来了一些复杂性

3. 关注版本变化：Ignite 10.x在架构上做了重大调整，开发前应仔细阅读更新日志

4. 渐进式采用：可以先使用CNG工作流进行开发，再根据需要决定是否保留原生文件夹

总结

Ignite框架在版本10中对Expo集成策略进行了调整，这是为了支持更多原生功能而做出的权衡。开发者需要根据项目实际需求选择合适的工作流，并理解不同选择带来的技术影响。通过合理配置和依赖管理，可以在保持开发效率的同时获得更好的应用性能。