CRA 为什么要做成“黑盒”

853 阅读2分钟

最近,在搭建某个业务系统的过程中,我选用了 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 黑盒,下篇再讲:)