jimmypaolini/codebase

conformetry-generate

Scaffold code with a conformetry generator instead of writing it by hand.

查看源码
仓库原始内容

按源仓库内容呈现,保留标题、案例、代码、表格、链接以及原文引用的演示图片。

Generating with conformetry

Conformetry generators render a template — an ordinary folder of ordinary files — into an instance on disk. The same template is then the standard the instance is measured against, so generating is not a convenience. Code written by hand in a shape a template already describes starts life failing conformance.

Before you write a file by hand, check for a generator

A generator name you guess at is rejected, so read the registry rather than inferring it:

bash
conformetry templates

In an Nx workspace, the emitted plugin answers the same question:

bash
nx list conformetry

Both read the live configuration, so they are correct for the workspace you are in. Neither output is worth caching in a note — it changes as generators are added.

Generation overwrites, unconditionally

There is no existence check, no skip-if-exists, no merge, and no conflict detection anywhere in the write path. Every file in the template is rendered and written over whatever is there.

Never point a generator at a path that already holds work you want. To change an existing instance, edit it. Regenerate only when you intend to discard what is there, or when the instance is missing files a template requires and you have read what will be replaced.

The Nx path writes through a Tree, so --dry-run is honest and shows exactly what would land:

bash
nx g conformetry:<generator> --name=<name> --project=<project> --dry-run

Do that first when you are unsure where output will go.

The two entrypoints disagree about inputs

This is the single most confusing thing about generating, and it is not a bug: the same generator behaves differently depending on how you invoke it.

Nx pluginCommand-line host
Invocationnx g conformetry:<name>conformetry generate --template <name>
Inputsevery declared input is requirednone is ever required
Missing inputrefuses, or promptsrefuses when the template interpolates it
Default destinationresolved from the workspacegenerated/<generator-name>

The remaining asymmetry is about when a missing value is caught. The Nx path requires every declared input up front, so it refuses before rendering starts. The command-line host requires none of them, and catches the omission at the moment a template asks for it — MissingSubstitutionError, naming the placeholder and the template file.

So an input a template never interpolates can be omitted on the command-line host and not on the Nx path. Anything a template does interpolate is required on both.

Pass every input explicitly on either path. A template that means "optional" says so with a section — {{#owner}}…{{/owner}} renders nothing when owner is absent — rather than relying on a bare {{owner}}.

A generator is addressed by its full name on both paths — there are no short alternative names. Both hosts list the real names when you get one wrong.

The flag is `--template`, not `--generator`. It matches the word the configuration (templatePath), the templates command, and the conformance report already use. --generator was removed rather than kept as an alias, and passing it is refused by name — this command accepts unknown flags so a template's inputs can be passed as flags, so without that refusal a stale script would have its --generator silently dropped and appear to work.

--template is also optional at the command line. Omitting it at a terminal offers an autocomplete over every configured template, each with its description; an agent shell is not a terminal, so always pass it — omitted there, the run is refused with the available names listed rather than left waiting on a prompt.

Where the output lands

On the Nx path the destination is resolved in this order, first match winning:

  1. An explicit --directory.
  2. No project input — treated as a new project, placed by its type input

alongside projects of the same type.

  1. A module input — placed in that existing module. Naming a module that does

not exist is an error, not an invitation to create one.

  1. The generator's own scoped directory, from the first tagged pattern in its

instance groups.

  1. The directory already holding the most instances of that generator.
  2. The project root.

Steps 4 and 5 are why a generator usually needs no destination at all: it knows where its own instances live. Reach for --directory when you are deliberately placing something outside that convention.

On the command-line host only --directory applies, and its absence means generated/<generator-name> — a scratch location, not your source tree. Always pass --directory there when you mean to write into the workspace.

Running without a person present

The command-line host prompts whenever stdin is a terminal, and there is no flag to turn that off — an attached terminal is the whole condition, so an agent shell, a hook, or a CI job is never prompted.

Every input a generator declares is required, on both entrypoints: a generator substitutes each of its placeholders, and mustache renders a missing one as an empty string rather than failing, so an optional input would quietly put a hole in the generated file. With no terminal, an input you did not pass is therefore a hard error naming the flag to pass — never a silent default, and never a menu drawn where nothing can answer it. Pass every input the template declares, or run where you can be asked.

After generating

Two steps, both cheap, both catching a whole class of mistake:

  1. Check conformance of what you just made. A generated instance conforms by

construction, so a difference means the destination was wrong, an input was empty, or you overwrote something. See the conformetry-validate skill.

  1. Implement inside the generated files. Do not build a parallel structure

beside them. The template's section comments and declarations are the contract; adding to them is always allowed, removing them is what breaks.

When a generator does not exist yet

Adding one is a configuration change, not a code change — see the conformetry-configure skill. Two things bite immediately after: the emitted Nx plugin has to be regenerated with nx sync, and every conformetry command refuses to run while it is out of date rather than working from stale definitions.

Seeing it rather than reading about it

`conformetry-examples` is eleven self-contained examples, each with its own configuration, template, instances, and command. Two are worth running before scaffolding something unfamiliar:

  • `hello-template` — the smallest generator that exists, generated and then

validated in two commands, so the loop is visible end to end.

  • `case-variants` — every derived case variant in paths and in contents,

and how an explicit input overrides one.

Each runs in about a second and its guide quotes the output it produces, which the package's own test suite asserts. See its AGENTS.md for which example answers which question.

来自同一仓库

更多 Skills

全部 Skills
jimmypaolini
社区

callidescope-configure

Tell callidescope what to do — the command-line flags (--check, --write, --addresses, --config, --format, and an override for every configured field, from --directories and --exclude through --include-tests, --maximum-depth, --maximum-breadth, --json, --markdown, and --mermaid) and the callidescope.config.ts they layer over, covering the two depth and breadth limits, entry points, exclusions and excluded callees, and where a run writes its JSON, markdown, and mermaid reports. Use when wiring a d

安装量
2
GitHub Stars
0
最近更新
9月26日
jimmypaolini
社区

callidescope-trace

Run callidescope and read what it printed — a whole-workspace trace, one project's gate verdict, or the depth and breadth commands against one or more callables, each addressed as filequalified-name. Use when running callidescope or npx callidescope, when reading a call stack or a breadth row, when reading what a per-project gate or trace target printed, when reading a project readme's Limits table, when a depth printed as "≥ n" needs interpreting, when reading a committed markdown report, merma

安装量
2
GitHub Stars
0
最近更新
9月26日
jimmypaolini
社区

codometer-triage

Act on a codometer limit breach, a comment budget breach, a stale committed report, or a run that failed outright. Use when a codometer --check exits non-zero, when a size or count limit was breached, when a comment block ran past its word, line, or character budget, when a committed report reads stale against a fresh measurement even though nothing changed, when a limit fails to bind or an input matches no files, or before reaching for a repository's limit value to make a failing check pass.

安装量
2
GitHub Stars
0
最近更新
9月26日