CRA 为什么要做成“黑盒”

最近，在搭建某个业务系统的过程中，我选用了 react 作为主要的技术栈。和同事的业务交流中，我提到了“黑盒”这个词汇。

在我司同事的强烈要求（火锅承诺）下，就有了今天这篇《CRA 为什么要做成“黑盒”》。

# 什么是“黑盒”

首先从前端 er 们熟悉的 vue-cli 说起，以下是vue 脚手架的基本目录：

再来看下 create-react-app 的项目目录：

在这里，我就不对每个文件进行介绍了。

相比 create-react-app，vue-cli 将配置文件完全暴露出来。但是，create-react-app 的基本目录中却隐藏了 config 相关的配置文件，当然 @vue/cli 也做了相关功能的实现。

对于这种方式我把它称之为“黑盒”，也就是我们今天的主题。

# 脚手架为什么要使用黑盒

一般的项目流程大致如下所示：

• 实现项目的基本结构，如基础设置搭建，测试；

• 过程中的文件配置，如 webpack eslint 等；

• 完成项目业务的一些功能需求。

在实际业务操作中，前面两项流程可以为后期的项目服务，进而减少很多重复性的工作。

所以，为了开发的方便性，我们完全可以用一个黑盒子把项目的基本架构和文件配置装起来，给后续开发者们留下一些“痕迹”，这样新手们就不需要担心项目的前期准备，达现开箱即用的体验。

开箱即用是给开发者提供的一种便利。

# 矛盾的黑盒自由

开发界有这样一条箴言：“新手渴望规则，老手渴望自由”。

随着开发者能力的提升，黑盒可能无法满足你的需求，娴熟的老手们越来越想解除黑盒的约束，都想去实现黑盒中文件的自由支配，但 @vue/cli 和 create-react-app 黑盒给老手们的自由度是完全不一样的。

• @vue/cli 给老手们留了实现黑盒自由的接口 vue-config.js

• create-react-app 的宗旨是，要么不给自由，要么把自由权全给你 npm run eject

技术大佬们对于 create-react-app 的黑盒是爱恨交加的，既想让它给予自由，又不想打破它的黑盒约束。

黑盒自由一旦被打破，整个操作是不可逆的，项目依赖项后期的版本更新就无人可做了。

所以有技术大佬投身于 CRA 的研究，最终实现了两方面都能兼得的效果，既能保证开发者受制于 CRA 黑盒，又能实现黑盒中文件配置的自由。

实现 react 中的 CRA 的依赖项是 react-app-rewired。

关于如何打破 react 中的 CRA 黑盒，下篇再讲：）