PHPackages moltark/moltark - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Templating & Views](/categories/templating) 4. / 5. moltark/moltark ActiveLibrary[Templating & Views](/categories/templating) moltark/moltark =============== Modern software project templater with first-class support for updates and template evolution. v0.0.1(3mo ago)00[1 issues](https://github.com/ophidiarium/moltark/issues)[3 PRs](https://github.com/ophidiarium/moltark/pulls)AGPL-3.0-onlyGoPHP >=8.0CI passing Since Apr 3Pushed 1mo agoCompare [ Source](https://github.com/ophidiarium/moltark)[ Packagist](https://packagist.org/packages/moltark/moltark)[ Docs](https://github.com/ophidiarium/moltark)[ RSS](/packages/moltark-moltark/feed)WikiDiscussions main Synced today READMEChangelogDependenciesVersions (2)Used By (0) moltark ======= [](#moltark) **Moltark** is a modern software project templater, powered by Starlark, with first-class support for updates and template evolution. It helps teams bootstrap new software projects from reusable templates and keep them aligned as those templates evolve over time. > **Why “moltark”?** > Like a snake molting its skin, a project can adopt a new shape without losing its identity. > Moltark is about evolving projects over time, not just generating them once. Status ------ [](#status) Moltark is at an early stage of development. This repository is in its initial setup phase while the implementation is being built. The published packages are early placeholder releases and do not yet provide the intended functionality. Documentation ------------- [](#documentation) Architecture and testing notes live in [`docs/`](./docs/README.md). Recommended reading order: - [`docs/README.md`](./docs/README.md) - [`docs/concepts/01-core-concepts.md`](./docs/concepts/01-core-concepts.md) - [`docs/concepts/02-modules-and-providers.md`](./docs/concepts/02-modules-and-providers.md) - [`docs/concepts/03-execution-model.md`](./docs/concepts/03-execution-model.md) - [`docs/testing.md`](./docs/testing.md) For the current component-centric direction, start with: - lightweight project anchors in [`docs/concepts/01-core-concepts.md`](./docs/concepts/01-core-concepts.md) - module/provider boundaries, first-class `json_file` / `toml_file` / `yaml_file` primitives, the minimal Go + VS Code example, and opaque root projects in [`docs/concepts/02-modules-and-providers.md`](./docs/concepts/02-modules-and-providers.md) Development ----------- [](#development) The repo now includes a Bazel build maintained with Gazelle using modern bzlmod configuration. Use [`bazelisk`](https://github.com/bazelbuild/bazelisk) so the version pinned in [`.bazelversion`](./.bazelversion) is selected automatically. Common commands: - regenerate and normalize Go `BUILD.bazel` files: `bazelisk run //:gazelle` - build the CLI: `bazelisk build //:moltark` - run the Bazel suite: `bazelisk test //...` - run the Go suite directly: `go test ./...` The Bazel setup is intentionally Gazelle-first: - `MODULE.bazel` owns external dependency resolution through `rules_go` and Gazelle's `go_deps` - the root [`BUILD.bazel`](./BUILD.bazel) owns the Gazelle entrypoint and repo-level directives - package-level `BUILD.bazel` files are generated and then only hand-maintained where Gazelle cannot infer runtime data such as fixtures, snapshots, and `.feature` files For Gherkin specifically: - feature files are modeled as first-class Bazel inputs through local `gherkin_library(...)` rules in [`tools/bazel/gherkin_defs.bzl`](./tools/bazel/gherkin_defs.bzl) - execution still goes through the existing Go `godog` suite - the local `godog_feature_test(...)` macro wires transitive `.feature` files into Bazel runfiles without pulling in a separate Ruby or C++ runtime The problem ----------- [](#the-problem) Most project generators are good at one thing: creating a starting point. That is useful, but incomplete. Once a project exists, template improvements rarely flow back cleanly into existing repositories. Teams usually end up doing one of three things: - copying changes by hand - regenerating and manually reconciling diffs - accepting drift and letting each repository slowly diverge This becomes especially painful in organizations that create many repositories over time. Every new project tends to repeat the same investment: - wiring CI/CD - setting up linters and formatters - enabling spell checking - configuring license validation - adding copy/paste detection - introducing complexity monitoring - setting up git hooks - establishing repository metadata and automation - applying security and compliance defaults - correctly wiring open source licensing and release flows All of that work is necessary. None of it should have to be redone from scratch for every repository. Moltark is built around a different model: - **bootstrap** projects from reusable templates - **compose** project conventions from smaller building blocks - **update** existing projects as templates evolve - keep generated output **reviewable**, **maintainable**, and **owned by the repository** Vision ------ [](#vision) Moltark aims to make project templates behave less like one-time scaffolding and more like evolving organizational building blocks. A template should not just help start a project. It should continue to carry engineering standards, quality controls, automation, and repository conventions forward as the project grows. In that model, project setup becomes a reusable and updatable asset for a team or organization rather than repeated manual work scattered across repositories. Why this matters even more in the AI era ---------------------------------------- [](#why-this-matters-even-more-in-the-ai-era) As software delivery becomes increasingly accelerated by AI agents, strong project foundations matter more, not less. Agent-driven development works best when repositories provide clear structure, strict feedback loops, and explicit quality boundaries. In practice, that means stronger defaults around: - rigorous linting and formatting - repository-wide conventions - copy/paste and duplication detection - complexity monitoring - reproducible automation - machine-readable project structure - shared skills and guidance for agents AI systems are fast, but they also amplify inconsistency when the surrounding project lacks guardrails. A weak repository setup does not stay weak for long under agent-driven change; it drifts faster. That makes updatable project templates even more valuable. The right defaults can be established once, then continuously improved and propagated as tooling, standards, and workflows evolve. This is especially important because these standards are changing quickly. In the AI era, project conventions are not static. New linters, duplication detectors, complexity watchers, repository policies, and agent workflows are emerging at a much higher rate than in traditional software environments. Moltark is designed for that reality: not just to generate projects, but to help them keep pace with rapidly evolving engineering standards, including CI/CD-integrated maintainability checks such as linting, duplication detection, and complexity monitoring with tools like [mehen](https://github.com/ophidiarium/mehen). Planned capabilities -------------------- [](#planned-capabilities) - Bootstrap new projects from reusable templates - Compose templates from smaller modules - Update existing projects to newer template versions - Keep template-driven changes understandable and reviewable - Support multiple languages and software ecosystems - Enable gradual project evolution instead of regeneration-heavy workflows Why Starlark ------------ [](#why-starlark) Moltark uses **Starlark** as its template and composition language. Starlark offers a useful balance of programmability, determinism, and composability. It is expressive enough for real project logic, while still constrained enough to remain understandable and portable. Starlark matters to Moltark, but it is not the main point. The main point is making software project templates composable, maintainable, and updatable over time. Why not just use a template generator? -------------------------------------- [](#why-not-just-use-a-template-generator) Traditional template generators are excellent for creating an initial repository, but they usually stop there. After generation, the relationship between the project and the template is mostly gone. Future improvements to the template do not naturally flow into already-generated repositories. Moltark is explicitly designed to keep that relationship alive. Why not Projen? --------------- [](#why-not-projen) Projen is powerful, but it is built around regeneration from code as the primary model. That works well in some ecosystems, especially when the generated surface is intentionally treated as derived output. But it becomes less satisfying when teams want: - more explicit control over updates - clearer reconciliation with manual edits - reusable template modules decoupled from one monolithic project-definition model - a solution that feels more like template evolution than full resynthesis Moltark is not trying to be “Projen in another language.” It is exploring a different model: project templating with first-class updates. Why not Copier? --------------- [](#why-not-copier) Copier is one of the closest conceptual neighbors to Moltark. It already recognizes that project templates should support updates, not just initial generation. That is directionally very aligned. The main difference is that Moltark aims to push harder on: - **composable template modules**, not just repository templates - **Starlark as a structured configuration and composition language** - a model that feels closer to reusable project building blocks than one template repository per project type Why not Bazel macros or rules? ------------------------------ [](#why-not-bazel-macros-or-rules) Bazel is excellent for build graphs, reproducibility, and structured configuration, but it is not primarily a project templating system. Moltark borrows some aesthetic and language inspiration from that ecosystem, but it targets a different problem: bootstrapping and evolving repository structure, configuration, and conventions over time. Design principles ----------------- [](#design-principles) - **Bootstrap is not enough** — templates should stay useful after day one - **Updates are first-class** — template evolution should be part of the model - **Composition over duplication** — project conventions should be reusable and modular - **Shared standards should be encoded once** — project setup should not be rebuilt from scratch for every repository - **Governance should be reusable** — quality, compliance, and automation defaults should travel with templates - **AI needs stronger guardrails, not weaker ones** — agent-driven development increases the value of consistent tooling and feedback - **Generated output should remain understandable** — users should be able to read, review, and own their repositories - **Projects should evolve, not be discarded and recreated** Early package status -------------------- [](#early-package-status) The current npm and PyPI packages are stub releases published during the project's early setup. They should not yet be considered functional releases of Moltark. Roadmap ------- [](#roadmap) Initial areas of focus: - Go CLI - Starlark module system - project bootstrap workflow - update and reconciliation engine Initial ecosystem support: - Go - Python - Rust After that, Moltark is expected to expand into: - Bazel, where Starlark-native and code-driven configuration are a particularly strong fit - broader support for ecosystems with code-based configuration, starting with TypeScript and Ruby - extensible config stubs that can evolve from generated defaults into maintainable project-owned code License ------- [](#license) AGPL ### Health Score 32 — LowBetter than 69% of packages Maintenance87 Actively maintained with recent releases Popularity0 Limited adoption so far Community8 Small or concentrated contributor base Maturity29 Early-stage or recently created project Bus Factor1 Top contributor holds 81.5% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Unknown Total 1 Last Release 93d ago ### Community Maintainers ![](https://www.gravatar.com/avatar/20b8cad989d8dd521c1d28c2b2446d5a06aed2db3e227d3576f25e361cd78737?d=identicon)[tinovyatkin](/maintainers/tinovyatkin) --- Top Contributors [![tinovyatkin](https://avatars.githubusercontent.com/u/5350898?v=4)](https://github.com/tinovyatkin "tinovyatkin (22 commits)")[![renovate[bot]](https://avatars.githubusercontent.com/in/2740?v=4)](https://github.com/renovate[bot] "renovate[bot] (5 commits)") --- Tags scaffoldingtemplateupdatesproject-generatorstarlark ### Embed Badge ![Health badge](/badges/moltark-moltark/health.svg) ``` [![Health](https://phpackages.com/badges/moltark-moltark/health.svg)](https://phpackages.com/packages/moltark-moltark) ``` ### Alternatives [phpoffice/phpword PHPWord - A pure PHP library for reading and writing word processing documents (OOXML, ODF, RTF, HTML, PDF) 7.6k39.0M237](/packages/phpoffice-phpword)[rize/uri-template PHP URI Template (RFC 6570) supports both expansion & extraction 435149.5M63](/packages/rize-uri-template)[mopa/bootstrap-sandbox-bundle Seperate live docs from code 256.8k](/packages/mopa-bootstrap-sandbox-bundle)[larablocks/pigeon A more flexible email message builder for Laravel 5 including chained methods, reusable message configurations, and message layout and template view management. 143.7k](/packages/larablocks-pigeon) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)