项目结构 — $mol

项目结构

$mol 项目有四层嵌套：你克隆下来的工作区、其中的包、包里的模块，以及模块里的文件。这套布局回答一个很实际的问题——新项目放在哪里、它的历史归谁——构建所做的几乎一切都由此而来。mam/ 工作区 —— 克隆下来的 MAM├── .meta.tree 登记表：哪个包来自哪个仓库├── mol/ 包 —— 框架本身，自己的 git 仓库└── my/ 包 —— 你的，你自己的 git 仓库 ├── .gitattributes 让构建出的二进制文件保持完好 ├── my.meta.tree 你自己项目的登记表 └── hello/ 项目 —— 一个模块，也是自己的 git 仓库 ├── index.html 入口（只有应用模块需要） ├── hello.view.tree 标记 └── form/ 子模块 —— $my_hello_form在本页，这份清单的每一行都带一个问号，说明它为什么在那里；下面的小节把同样的事讲得更细。

开一个项目

五步。只有第一步会重复，后三步可以交给脚手架。1. 克隆工作区，一次。从此以后你写的一切都住在里面。1git clone https://github.com/hyoo-ru/mam.git2cd mam2. 建一个属于你的包。一个短名目录——你的名字、你的公司、你的 ID——并且是一个独立的 git 仓库。它是你今后所有项目的容器：1mkdir my2cd my3git init把它推到你放代码的地方，公开或私有都行。顺手加一个只有 * -text 一行的 .gitattributes；原因见下面关于包的小节。3. 加上登记表。 my/my.meta.tree 是你包里项目的清单。它一开始是空的，每个项目一行：1pack hello git \https://github.com/you/hello.gitMAM 读它的方式，和读上一层工作区的 .meta.tree 完全一样，所以同事克隆 my/ 时也会拿到这些项目。4. 建项目，并给它自己的仓库。目录就是组件——my/hello/ 就是 $my_hello——它的历史属于它自己，不属于你的包，也不属于 $mol：1mkdir hello2cd hello3git init这种分离正是布局的用意：my/hello/ 里的提交进入 hello 仓库，永远不会进 my，也不会进 mol。5. 登记它。把第 3 步的 pack 行写进 my/my.meta.tree，之后新的检出就会按名字把项目取回来。第 2 步之后的任何时候，

脚手架都能替你写出一个能跑的模块：1npx create-view-tree-lsp my/hello

工作区

MAM 只克隆一次，然后就在里面工作。它不是一个把依赖复制进来的文件夹：每个包都以自己的 git 克隆形式待在那里，带着完整历史，所以你可以读框架的源码、往里面放一个 debugger，并从同一份工作副本发起 pull request。根目录的 .meta.tree 就是让这一切成立的注册表：1pack mol git \https://github.com/hyoo-ru/mam_mol.git2pack hyoo git \https://github.com/hyoo-ru/mam_hyoo.git3pack lib git \https://github.com/hyoo-ru/mam_lib.git当构建遇到 $mol_view 而 mol/ 文件夹还不存在时，它会到这里查这个名字并克隆仓库。没有任何东西被 vendor 进来，也没有任何东西被拍平。

包

顶层文件夹就是一个包，而包就是一个 git 仓库。你自己的包只是一个由你命名的文件夹：只要它还留在本地，就不需要任何登记；等到你想按名字拉取它的那天，再加一行 pack。包可以嵌套。一个包能为自己内部的文件夹携带自己的 pack 声明，MAM 从将要容纳该包的那个文件夹的 meta.tree 中读取它们。本站位于 bog/smalljs/，本身就是一个仓库，登记在 bog/bog.meta.tree 里；而后者又位于根 .meta.tree 所列的 bog/ 克隆之中。

每个包都需要的一个文件

会被部署的包需要一个只有一行内容的 .gitattributes：1* -text在 GitHub 上编辑此页这有帮助吗？是否上一页从 TypeScript 到 view.tree 下一页工具链本页内容开一个项目工作区包每个包都需要的一个文件模块模块里的文件生成的文件夹以短横线开头 meta.tree 实际做的事下一步