Um projeto $mol tem quatro níveis aninhados: o workspace que você clonou, os pacotes dentro dele, os módulos dentro dos pacotes e os arquivos dentro de um módulo. O arranjo responde a uma pergunta prática — onde vai um projeto novo e de quem é o seu histórico — e quase tudo o que o build faz decorre disso.mam/ workspace — o checkout do MAM├── .meta.tree registro: qual pacote vem de qual repositório├── mol/ pacote — o próprio framework, repositório git próprio└── my/ pacote — o seu, seu próprio repositório git ├── .gitattributes mantém os binários compilados intactos ├── my.meta.tree registro dos seus próprios projetos └── hello/ projeto — um módulo, e um repositório git próprio ├── index.html ponto de entrada (só módulos de aplicação) ├── hello.view.tree a marcação └── form/ submódulo — $my_hello_formNesta página cada linha da listagem traz um ponto de interrogação com o motivo de estar ali; as seções abaixo dizem o mesmo com mais calma.
Cinco passos. Só o primeiro se repete, e o scaffolder pode fazer os três últimos por você.1. Clone o workspace, uma vez. Tudo o que você escrever daqui em diante vive dentro dele.1gitclonehttps://github.com/hyoo-ru/mam.git2cdmam2. Crie um pacote seu. Uma pasta curta — seu nome, sua empresa, seu apelido — e um repositório git próprio. É o contêiner de todo projeto que você começar:1mkdirmy2cdmy3gitinitPublique-o onde você guarda código, público ou privado. Já aproveite e coloque um .gitattributes com a única linha *-text; o motivo está abaixo, na seção sobre pacotes.3. Adicione o registro.my/my.meta.tree é a lista dos projetos dentro do seu pacote. Ele começa vazio e ganha uma linha por projeto:1pack hello git \https://github.com/you/hello.gitO MAM o lê do mesmo jeito que lê o .meta.tree do workspace um nível acima, então um colega que clonar my/ recebe os projetos também.4. Crie o projeto, com repositório próprio. A pasta é o componente — my/hello/ é $my_hello — e o histórico pertence a ele, não ao seu pacote nem ao $mol:1mkdirhello2cdhello3gitinitEssa separação é o ponto do arranjo: um commit em my/hello/ vai para o repositório hello, nunca para my e nunca para mol.5. Registre-o. Acrescente a linha pack do passo 3 em my/my.meta.tree, e um checkout novo do seu pacote busca o projeto pelo nome.O scaffolder escreve um módulo funcional para você a qualquer momento depois do passo 2:1npxcreate-view-tree-lspmy/hello
Você clona o MAM uma vez e trabalha dentro dele. Não é uma pasta para onde as dependências são copiadas: cada pacote fica ali como um checkout git próprio, com histórico, então você pode ler o código-fonte do framework, colocar um debugger nele e abrir um pull request a partir da mesma cópia de trabalho.O .meta.tree da raiz é o registro que faz isso funcionar: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 a build encontra $mol_view e ainda não existe uma pasta mol/, ela procura o nome aqui e clona o repositório. Nada é vendorizado e nada é achatado.
Uma pasta de primeiro nível é um pacote, e um pacote é um repositório git. O seu próprio pacote é só uma pasta que você nomeia: enquanto ficar local, não precisa de registro nenhum, e de uma linha pack no dia em que você quiser buscá-lo pelo nome.Pacotes se aninham. Um pacote pode carregar suas próprias declarações pack para as pastas dentro dele, e o MAM as lê do meta.tree da pasta que vai conter o pacote. Este site vive em bog/smalljs/ e é um repositório à parte, listado em bog/bog.meta.tree, que por sua vez está dentro do checkout bog/ listado no .meta.tree da raiz.
