脚手架与业务目录的目录结构浅析

[hoperyy]

脚手架与业务目录的目录结构浅析

嵌套结构

一般情况下，脚手架和业务代码是出于上下级的关系，即脚手架在外层、项目目录在内层，如下所示，称为 嵌套结构

webpack.config.js
gulpfile.js
postcss.config.js
.babelrc
package.json
src/
   /index.html
   /index.js
   /index.less

这种目录结构的优点是：兼容性好，脚手架编写快速。因为是嵌套型的关系，很多 webpack 模块的依赖查找逻辑就是依次向上递归查找的。

但是这种目录结构有下面几个缺点：

• 容易和业务代码混淆。

  项目依赖和脚手架依赖混淆。

• 不够安全。

  脚手架代码被另一位项目成员不小心修改后，会影响到其他人的开发。

非嵌套结构

和 嵌套结构 结构对应，我们希望项目的目录结构是脚手架和业务代码不是内外层的关系，而是各自独立，互不影响。称为 非嵌套结构。

非嵌套结构 解决了上面 嵌套结构 的两个缺点：

项目代码和脚手架代码互相独立，互不影响。

团队协作中，开发者只需要关注业务代码，无需接触脚手架，更安全。

谈谈 .babelrc、postcss.config.js 等

babel-loader 在编译业务代码中的 es6 语法时，会尝试查找 babel 的配置项，它有两种方式查找：

• 从被编译文件所在的目录开始，一层层向上级目录递归，直到找到 .babelrc 配置文件为止；否则报错。

  该逻辑需要脚手架和业务代码属于嵌套结构

• 从 webpack 的 babel-loader.options 配置项中查找配置；否则报错。

  脚手架和业务代码可以属于非嵌套结构，但对脚手架的编写有一定要求（需要额外配置，如 babel-loader.options、resolve.modules 等）

postcss 也是这样的逻辑，只不过它的配置文件叫 postcss.config.js。

很显然，babel 和 postcss 这两种 webpack 的 loader 都是可以支持嵌套和非嵌套。

但是，如果用到某个 loader 或插件，只提供了向上递归查找配置文件的逻辑，而未提供 webpack 配置项的话，就只能通过嵌套型的结构解决了。

这种情况是不可控的，所以，嵌套型的目录结构最为保险。

我们需要什么样的目录结构以及如何实现

• 理想的目录结构

  在团队人数较多，脚手架各种各样，业务变化快速的背景下，我们需要的是这样的目录结构：

  • 非嵌套
  • 业务目录不出现 .babelrc、postcss.config.js 这样的配置文件
  • 脚手架编写尽可能简单

• 如何实现

  • 方案一：对于某些特定的脚手架，可以通过 webpack 内部配置项来实现非嵌套型的目录结构。

    这种方案的缺点是：（1）需要额外配置；（2）不能保证 babel 和 postcss 之外的插件也能支持 webpack 内部配置的方式。

  • 方案二：将业务目录的软链接置于脚手架目录内部

    这种方案和方案一其实是一样的，因为程序在进入软链接目录编译业务代码时，仍然会沿用原路径，而不是软链接所在的脚手架目录里的路径。

  • 方案三：将业务目录复制到脚手架目录并实时监听

    该方案的优点是无需脚手架做针对性配置即可使用。

    缺点是复制是一个比较重的操作。

  • 方案四：将业务目录的硬连接生成到脚手架目录并实时监听

    相对于方案三的 “复制”，该方案更轻量、快速。

    在公司实际业务运行过程中，这种方案被采用并运行的还算不错。推荐使用这种方式。

参考资料

• 纠结的链接：ln、ln -s、fs.symlink、require
• github issue: Don't resolve symlinks when requiring
• github: sync-directory