Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

模块管理之纠结

  传统前端架构下的目录设计通常会把 html、css、js 文件放到单独的目录中存储。后来也有人稍微改变了一下模式,把目录按业务来分,但实际上并没有解决目录结构混乱的问题。基于组件化的前端架构就可以将目录清晰地分出来,但可能实际开发中并不容易维护。
  npm 的包嵌套就是一个典型的组件化模式。每个组件中都有 package.json 和 node_modules,一个用来描述组件的基本信息,一个用来存放依赖。然后 node_modules 目录中又有一坨组件,里面会同样照着这种模式一级级嵌套下去。这个结构是很清晰的,我们总是可以在固定的位置找到组件的基本信息和相关的依赖。但这样的模式会使目录嵌套很深,每次要定位到一个文件都会很麻烦。
  npm 的另一个问题就是底层模块无法通用。比如有一个项目,它依赖了 A、B、C 三个组件,而这三个组件都依赖了一个名叫 X 的组件。那么组件 X 将分别被安装到 A、B、C 的 node_modules 中,而不是建立一个通用的 X。所以经常会发现明明没用多少东西,项目的 node_modules 目录却很大很大。
  为了解决这个问题就有了 peerDependencies 的概念。普通的 dependencies 是将依赖作为当前组件的子组件安装,而 peerDependencies 则将依赖平行地安装。也就是说即使 A、B、C 三个组件都依赖了 X,那么 X 也只是被安装成了与 A、B、C 同级的一个组件而已,不会被多次复制。
  然而据说 npm 3 已经不会默认安装 peerDependencies 的依赖,而是需要手动地安装。这是因为还存在一个版本冲突的问题。假如 A、B、C 三个模块所依赖的 X 模块是不同的版本,那么把 X 模块平行地安装下来就会遇到版本冲突。
  我觉得 peerDependencies 的概念是非常好的,只是 npm 不支持「同时安装某个模块的多个版本」而已。如果所有的模块都是 peerDependencies 模式的依赖,那么依赖的层级关系就会完全消失。当所有依赖都是同级依赖的时候就不会有一坨奇怪的问题。
  同级依赖也是有一定局限性的,因为这就让每个模块变得必须命名。所有的 npm 包都必须有唯一的名字,npm 就是基于这个前提来设计的。如此一来,当包的数量越来越多时,命名就会词穷。然后就出现各种奇怪的名字,导致项目变成一坨谁都看不懂的东西。
  反正我至今也没找到一套完美的依赖解决方案,npm 虽然算是一个通用方案,但和完美的距离还差太远。
网名:
3.84.186.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^