@airmark/quiver

中文文档
0.42.1发布于 2026/10/31Apache-2.0ES Module零依赖构建来源已验证近 30 天下载 2937

Airmark Quiver — Air Force, DAF and Army document Quills for Quillmark.

原始使用文档
文档目录9 节
  1. Contents
  2. Install
  3. Usage
  4. Load from the installed directory (Node)
  5. Load over HTTP (browser)
  6. Layout
  7. Templates
  8. Working on a quill
  9. License

@airmark/quiver

A Quillmark source quiver of Air Force, DAF and Army official-document quills, sourced from tonguetoquill-collection and aligned to the current Quillmark spec.

Contents

QuillVersionDescription
usaf_memo0.3.0USAF / DAF Official Memorandum (AFH 33-337)
usaf_memo0.2.0Previous release, retained so documents pinned to @0.2 keep resolving
usaf_letter0.1.0USAF / DAF Personal Letter (AFH 33-337)
usaf_paper0.1.0Point, talking, bullet background, background, and position papers (AFH 33-337)
army_memo0.1.0U.S. Army Memorandum (AR 25-50)
medal_citation0.1.0Achievement, Meritorious Service, and Commendation Medal citations
af41410.1.0AF Form 4141 — Individual's Record of Duties and Experience (Ground Environment)
daf12060.1.0DAF Form 1206 — Nomination for Award
daf43920.1.0DAF Form 4392 — Pre-Departure Safety Briefing (Page 2)
afmc_moa0.0.1DoD Memorandum of Agreement (DoDI 4000.19)
classic_resume0.1.0Classic single-page resume
cyber_career_plan0.1.017X Cyber Operations Officer career plan: current assignment, vectors and record

Install

npm install @airmark/quiver @quillmark/quiver @quillmark/wasm

This package ships the source-quiver assets (Quiver.yaml + quills/) and the official templates, and exposes no JavaScript API. Loading is @quillmark/quiver's, rendering is @quillmark/wasm's.

Usage

Load from the installed directory (Node)

Resolve this package's Quiver.yaml from your own module — your dependencies are reachable from you, not from the loader's install location — and hand its directory to fromDir:

import { createRequire } from 'node:module';
import { dirname } from 'node:path';
import { Engine, init } from '@quillmark/wasm';
import { fromDir } from '@quillmark/quiver/node';

// `init` is the only door to `Document`: there is no static export to reach early.
const { Document } = await init();

const root = dirname(createRequire(import.meta.url).resolve('@airmark/quiver/Quiver.yaml'));
const quiver = await fromDir(root);
const engine = new Engine();

const doc = Document.fromMarkdown(`~~~
$quill: [email protected]
$kind: main
memo_for: ["ORG/SYMBOL"]
memo_from: ["ORG/SYMBOL", "Organization Name", "123 Street Ave", "City ST 12345-6789"]
subject: Hello Quillmark
signature_block: ["FIRST M. LAST, Rank, USAF", "Duty Title"]
~~~

Body of the memo.`);

const quill = await quiver.getQuill(doc.quillRef);
const { artifacts } = await engine.render(quill, doc, { format: 'pdf' });

A quill from getQuill is borrowed: every caller asking for that ref gets the same instance, so it is not yours to free().

Load over HTTP (browser)

A browser cannot read the source layout, so pack it at deploy time and serve the output as static files:

import { build } from '@quillmark/quiver/node'; // build step
await build(root, './public/quivers/airmark');
import { Quiver } from '@quillmark/quiver'; // browser runtime
const quiver = await Quiver.fromBuiltUrl('/quivers/airmark/');

Layout

This package is a source quiver conforming to the canonical layout:

Quiver.yaml
quills/
  <name>/
    <x.y.z>/
      Quill.yaml
      plate.typ
      assets/
      packages/
templates/
  templates.json
  <file>.md

Templates

templates/ holds the official starter documents Tongue to Quill offers in its template library. They sit beside the quiver rather than inside it: the quiver loaders never read them, and a consumer reaches them as files, through @airmark/quiver/templates/templates.json and the Markdown it names. Each entry is { id, name, description, file, tags }, and every listed template is live.

An entry's id is permanent. Tongue to Quill derives the template's row id and its shareable short code from it, so renaming one retires the old template (its stars and its short code with it) and publishes a new one. Removing an entry retires it the same way.

npm test renders every template against this quiver after quillkit check, and a warning fails it as an error does, so a quill change that breaks a template fails here rather than on the app's build.

Working on a quill

Two verbs, and they answer different questions.

Both verbs are quillkit's, the quill author's toolchain. It carries @quillmark/quiver and @quillmark/wasm at exact versions, so upgrading quillkit upgrades the format the quiver is packed in and the wasm the gate renders through. This collection pins the same two versions for scripts/check-examples.mjs and scripts/check-templates.mjs, which render through them.

Does it work? quillkit check loads the collection with fromDir, compiles every quill, and renders each one's seed, every field absent but what a card kind's seed: writes and rendering its default: or its blank, and its example, one filled-in page of made-up values: the seed with each field's example: and each kind's body.example committed, one card per kind. npm test then fails a quill that declares no example or whose example warns, and a template that warns. It is the gate CI runs, so a validation failure surfaces here rather than on a consumer's build:

npm install
npm test

The gate renders one answer per quill, so a page with a long list or a wrapping value in it is a design fixture's to exercise (design/).

What is it like to use? npm run dev is quillkit serve: it packs this quiver, drafts included, serves the studio client over it, and repacks on every save — pick a quill, edit its example (or, with Examples off, its seed), watch it paint, read the diagnostics. The client is quillkit's own, so there is nothing to install for it and nothing to keep in step.

Reload to pick up a repack. Editing a quill into an invalid state is not a failure of the loop: it packs, and the client says what is wrong with that quill and where, while the others stay usable.

quillkit check is what CI blocks on, so the gate is authoritative and studio is advisory, though both render through the wasm quillkit carries.

npm run build writes the arrangement a deploy serves into dist/ — the client at the root, a built quiver at quiver/ beneath it — without serving it. It passes --drafts, so the 0.0.x prototypes are packed beside the releases, and npx quillkit preview serves it as a static host will. CI uploads that on every run, so a pull request — a fork's included — is reviewed by downloading the artifact and serving the directory. Studio does not open the templates; npm test is what gates them.

main is deployed to GitHub Pages by .github/workflows/studio.yml, which runs that same command and keeps the deploy here: nothing outside this repository holds pages: write.

vercel.json deploys the same layout to Vercel, where a pull request gets a preview URL instead of an artifact to download. It carries the build, the output directory and the one cache rule a host owes this layout — assets/* immutable, which is studio's own bundle, and everything else already right by default. Importing the repository is the rest of the setup. Both deploys run off main and neither knows about the other.

License

Apache-2.0, the quill packages under quills/ included, except classic_resume's ttq-classic-resume, which is MIT. Two things a quill carries are not the project's to license: the fonts its package bundles, which keep their own upstream terms — see the packages/ directory inside each quill — and the DoD and DoW seals under quills/*/*/assets/, which are US Government insignia and whose use is governed as such.

版本与发布记录

@airmark/quiver 共发布 64 个版本,首次发布于 2026/04/25;过去 12 个月发布了 64 个版本。最新版本附带 npm provenance 构建来源证明,可追溯到公开的 CI 构建记录。

版本发布日期距今
0.42.1latest2026/10/317 天前
0.42.02026/10/299 天前
0.41.02026/10/2612 天前
0.40.02026/10/2315 天前
0.39.02026/10/1919 天前
0.38.02026/10/1919 天前

关于 @airmark/quiver 的常见问题

@airmark/quiver 是什么?

Airmark Quiver — Air Force, DAF and Army document Quills for Quillmark.

如何安装 @airmark/quiver?

在项目目录运行 npm install @airmark/quiver,或使用 pnpm add / yarn add / bun add。

@airmark/quiver 支持 TypeScript 吗?

该包的 package.json 没有声明类型入口。需要类型提示时,可以在 npm 上查找社区维护的 @types/airmark__quiver 是否存在。

@airmark/quiver 支持 ESM 还是 CommonJS?

以 ES Module 形式发布,推荐使用 import 引入。在 CommonJS 项目中,Node.js 20.19+ / 22.12+ 可以直接 require() 不含顶层 await 的 ES Module,更早的版本需要改用动态 import()。

@airmark/quiver 需要什么版本的 Node.js?

package.json 的 engines 字段要求 Node.js >=24。版本不符时 npm 默认只给出警告,开启 engine-strict 后会拒绝安装。

@airmark/quiver 可以商用吗?

@airmark/quiver 使用 Apache-2.0 许可。宽松许可:允许商业使用、修改和再分发,并附带明确的专利授权;分发时需保留许可与 NOTICE 文件,修改过的文件要注明改动。以上为概括,不构成法律意见,请以许可原文为准。

@airmark/quiver 的下载量有多少?

根据 npm 官方下载统计,@airmark/quiver 在 2026/10/05 – 2026/11/03 这 30 天内被下载 2,937 次,日均约 98 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入,适合横向比较热度,不能直接等同于使用人数。

@airmark/quiver 还在维护吗?

最新版本 0.42.1 发布于 2026/10/31(7 天前);至今共发布 64 个版本,其中过去 12 个月发布了 64 个;首次发布于 2026/04/25。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。