$mol works in any editor, but a small set of tools makes .view.tree and typed styles far more comfortable: a project scaffolder, a language server, editor integrations for Zed and VS Code, and a skill that teaches LLM assistants the framework.
create-view-tree-lsp generates a ready-to-run $mol module so you do not assemble the boilerplate by hand:1npxcreate-view-tree-lspbog/myappRun it from the root of your MAM checkout: module paths are resolved from there, and that is where the project has to live. Outside a workspace the command warns instead of leaving you to find out at the first build.The argument is the module path (namespace/name, or the equivalent bog_myapp). It writes the view.tree, view.ts, view.css.ts, and index.html for a working app, plus the GitHub Actions to deploy it.Everything the scaffolder knows how to add is included by default. You name only what you do not want:1npxcreate-view-tree-lspbog/myapp--no-tauri--no-backend--no-baza — a Giper Baza local-first store--no-docker — a Docker setup with docker-compose.yml and an nginx config--no-tauri — a Tauri desktop shell--no-backend — a $mol_server REST backend with node:sqlite storage and a shared TypeScript item type--no-prerender, --no-seo — search-engine visibility, described under Continuous integration belowA flag it does not know stops the run, so a typo cannot quietly leave something in.The scaffolder is a thin wrapper over the CLI in the language server, so npxview-tree-lspcreatebog/myapp does the same thing directly.
Translations live next to their module, in <module>/<name>.locale=<lang>.json. That is convenient for the code and awkward for a translator: thirty small files instead of one list of phrases.$yuf_localizer closes that gap. Point it at your project URLs and language codes, and it shows every key in one searchable list, marking the ones that still need work: keys that exist only in English, keys you changed but have not committed, and stale keys that the project no longer has. Translations are kept in the browser until you export them, so nothing is lost between sessions.When the translator is done, export the result and spread it back across the modules:1# from the MAM root2npxview-tree-lsplocalebog/myapp/app/---exclude=mol--updateThe argument is a folder or a single locale file. Flags:Every key carries its own module path, so $my_page_greeting lands in my/page/page.locale=ru.json, next to the sources it belongs to. Working out which module that is, though, is subtler than it looks: _ separates folders and words alike, so the longest matching folder path is the wrong answer. In $my_page_lang_hint the property starts with lang, and a real my/page/lang submodule next door would swallow the key. So the command asks each candidate module which keys it declares — MAM writes exactly those into its -view.tree locale file — and gives the key to the module that owns it.
