A $mol project has four nested levels: the workspace you cloned, the packages inside it, the modules inside those, and the files inside a module. The layout answers one practical question — where a new project goes and what owns its history — and almost everything the build does follows from it.mam/ workspace — the MAM checkout├── .meta.tree registry: which package comes from which repo├── mol/ package — the framework, its own git repo└── my/ package — yours, its own git repo ├── .gitattributes keeps built binaries intact ├── my.meta.tree registry of your own projects └── hello/ project — a module, and a git repo of its own ├── index.html entry point (app modules only) ├── hello.view.tree the markup └── form/ submodule — $my_hello_formOn this page every line of that listing carries a question mark with the reason it is there; the sections further down say the same at length.
Five steps. Only the first one is ever repeated, and the scaffolder can do the last three for you.1. Clone the workspace, once. Everything you write from now on lives inside it.1gitclonehttps://github.com/hyoo-ru/mam.git2cdmam2. Make a package of your own. One short folder — your name, your company, your handle — and a git repository of its own. It is the container for every project you will start:1mkdirmy2cdmy3gitinitPush it wherever you keep code, public or private. Add a .gitattributes with a single *-text line while you are there; the reason is below.3. Add the registry.my/my.meta.tree is the list of projects inside your package. It starts empty and gets a line per project:1pack hello git \https://github.com/you/hello.gitMAM reads it the same way it reads the workspace .meta.tree one level up, so a colleague who clones my/ gets the projects too.4. Create the project, with a repository of its own. The folder is the component — my/hello/ is $my_hello — and its history belongs to it, not to your package and not to $mol:1mkdirhello2cdhello3gitinitThat separation is the point of the layout: a commit in my/hello/ goes to the hello repository, never to my and never to mol.5. Register it. Add the pack line from step 3 to my/my.meta.tree, and a fresh checkout of your package fetches the project by name.The scaffolder writes a working module for you at any point after step 2:1npxcreate-view-tree-lspmy/hello
You clone MAM once and work inside it. It is not a folder that dependencies get copied into: every package sits there as its own git checkout, with history, so you can read the framework's source, put a debugger in it, and open a pull request from the same working copy.The root .meta.tree is the registry that makes this work: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.gitWhen the build meets $mol_view and there is no mol/ folder yet, it looks the name up here and clones the repository. Nothing is vendored and nothing is flattened.
A top-level folder is a package, and a package is a git repository. Your own package is just a folder you name — it needs no registration while it stays local, and a pack line the day you want it fetched by name.Packages nest. A package can carry its own pack declarations for the folders inside it, and MAM reads them from the meta.tree of the folder that will contain the package. This site lives at bog/smalljs/ and is a repository of its own, listed in bog/bog.meta.tree, which is itself inside the bog/ checkout listed in the root .meta.tree.
