Un progetto $mol ha quattro livelli annidati: il workspace che hai clonato, i pacchetti al suo interno, i moduli dentro i pacchetti e i file dentro un modulo. La disposizione risponde a una domanda pratica — dove va un nuovo progetto e a chi appartiene la sua storia — e quasi tutto ciò che fa la build discende da lì.mam/ workspace — il checkout di MAM├── .meta.tree registro: quale pacchetto viene da quale repository├── mol/ pacchetto — il framework stesso, repository git proprio└── my/ pacchetto — il tuo, repository git tuo ├── .gitattributes tiene intatti i binari compilati ├── my.meta.tree registro dei tuoi progetti └── hello/ progetto — un modulo, e un repository git suo ├── index.html punto d'ingresso (solo moduli applicativi) ├── hello.view.tree il markup └── form/ sottomodulo — $my_hello_formIn questa pagina ogni riga dell'elenco porta un punto interrogativo con il motivo per cui sta lì; le sezioni più sotto dicono la stessa cosa per esteso.
Cinque passi. Solo il primo si ripete, e lo scaffolder può fare gli ultimi tre al posto tuo.1. Clona il workspace, una volta. Tutto ciò che scriverai da qui in poi vive al suo interno.1gitclonehttps://github.com/hyoo-ru/mam.git2cdmam2. Crea un pacchetto tuo. Una cartella corta — il tuo nome, la tua azienda, il tuo handle — e un repository git suo. È il contenitore di ogni progetto che avvierai:1mkdirmy2cdmy3gitinitPubblicalo dove tieni il codice, pubblico o privato. Già che ci sei, aggiungi un .gitattributes con l'unica riga *-text; il motivo è più sotto, nella sezione sui pacchetti.3. Aggiungi il registro.my/my.meta.tree è l'elenco dei progetti dentro il tuo pacchetto. Parte vuoto e riceve una riga per progetto:1pack hello git \https://github.com/you/hello.gitMAM lo legge esattamente come il .meta.tree del workspace un livello sopra, così un collega che clona my/ si porta a casa anche i progetti.4. Crea il progetto, con un repository suo. La cartella è il componente — my/hello/ è $my_hello — e la sua storia appartiene a lui, non al tuo pacchetto né a $mol:1mkdirhello2cdhello3gitinitQuesta separazione è il senso della disposizione: un commit in my/hello/ va nel repository hello, mai in my e mai in mol.5. Registralo. Aggiungi la riga pack del passo 3 in my/my.meta.tree, e un checkout fresco del tuo pacchetto prende il progetto per nome.Lo scaffolder ti scrive un modulo funzionante in qualsiasi momento dopo il passo 2:1npxcreate-view-tree-lspmy/hello
MAM lo cloni una volta e ci lavori dentro. Non è una cartella in cui vengono copiate le dipendenze: ogni pacchetto sta lì come checkout git a sé, con la sua storia, così puoi leggere il sorgente del framework, metterci dentro un debugger e aprire una pull request dalla stessa copia di lavoro.Il .meta.tree di radice è il registro che rende possibile tutto questo: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.gitQuando la build incontra $mol_view e non c'è ancora una cartella mol/, cerca il nome qui e clona il repository. Nulla viene vendorizzato e nulla viene appiattito.
Una cartella di primo livello è un pacchetto, e un pacchetto è un repository git. Il tuo pacchetto è semplicemente una cartella a cui dai un nome: finché resta locale non ha bisogno di registrazione, e di una riga pack il giorno in cui vorrai recuperarlo per nome.I pacchetti si annidano. Un pacchetto può portare le proprie dichiarazioni pack per le cartelle al suo interno, e MAM le legge dal meta.tree della cartella che conterrà il pacchetto. Questo sito vive in bog/smalljs/ ed è un repository a sé, elencato in bog/bog.meta.tree, che a sua volta sta dentro il checkout bog/ elencato nel .meta.tree di radice.
