plugins/lisa-harper-fabric-agy/skills/harper-config-yaml/SKILL.md
--- name: harper-config-yaml description: This skill should be used when creating or editing a Harper (HarperDB/Fabric) component's config.yaml — enabling a built-in extension (graphqlSchema, jsResource, rest, static, roles, loadEnv, dataLoader, fastifyRoutes), wiring an external component, or troubleshooting why an extension is not loading. Critical: it documents the no-merge footgun where a custom config.yaml replaces Harper's default config entirely. Pairs with harper-component-model, harper-
npx skillsauth add codyswanngt/lisa plugins/lisa-harper-fabric-agy/skills/harper-config-yamlInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
A Harper component is configured by a single config.yaml at the component root
(harper-app/config.yaml in this project). It declares which extensions are
active and which files each extension reads. Extensions are enabled here, not
installed — the built-ins ship with Harper.
The structure is a map of extension name to its options:
extensionName:
option-1: value
option-2: value
If a component has no config.yaml, Harper applies this default automatically:
rest: true
graphqlSchema:
files: '*.graphql'
roles:
files: 'roles.yaml'
jsResource:
files: 'resources.js'
fastifyRoutes:
files: 'routes/*.js'
urlPath: '.'
static:
files: 'web/**'
The moment you add a custom config.yaml, it replaces this default entirely —
Harper does not merge your file with the defaults. If you write a config.yaml
that only enables static, you have silently turned off rest, graphqlSchema,
jsResource, and roles. This is the most common Harper config mistake.
Rule: when you add or edit config.yaml, re-declare every extension the app
actually needs — start from the default block above and add to it. Do not assume
unmentioned extensions stay on.
| Key | Purpose | Common options |
| --- | --- | --- |
| rest | Auto REST endpoints for exported resources/tables | true, or an object with options |
| graphqlSchema | Define tables/types from GraphQL files | files: '*.graphql' — see [[harper-schema-graphql]] |
| jsResource | Load custom JS resources | files: 'resources.js' — see [[harper-resources]] |
| static | Serve static files over HTTP | files: 'web/**', urlPath |
| roles | Role-based access control | files: 'roles.yaml' |
| loadEnv | Load env vars from .env | files |
| dataLoader | Seed tables from JSON/YAML | files |
| fastifyRoutes | Custom Fastify routes | files: 'routes/*.js', urlPath |
A component you depend on from npm needs a package: directive matching a
package.json dependency:
'@harperdb/nextjs':
package: '@harperdb/nextjs'
files: './'
A custom plugin you author is wired with pluginModule (point at the built JS, not
TypeScript source):
pluginModule: ./dist/index.js
The deprecated Extension API used extensionModule instead. Prefer pluginModule.
See [[harper-component-model]] for the plugin-vs-extension distinction.
config.yaml is source and lives at harper-app/config.yaml. It is part of
the deployable surface Fabric packages — keep it at the component root.config.yaml points to (resources.js, web/**) are generated by
bun run build from TypeScript under src/. Editing config.yaml to point at a
new file means the build must produce that file. See [[harper-build-and-deploy]].config.yaml change is a deploy-shape change: update the matching project doc
(the Fabric runbook) in the same change, and re-run the smoke command.config.yaml. Use loadEnv / environment variables and
document where secrets live without recording their values.After editing config.yaml, confirm the app still boots and the expected surface
is live: run harper dev harper-app (or the project's run command) and check that
the REST/GraphQL/static endpoints you rely on respond. A config that silently
dropped an extension often fails only at runtime, not at build time.
development
Use Expo DOM components to run web code in a webview on native and as-is on web. Migrate web code to native incrementally.
development
Guidelines for upgrading Expo SDK versions and fixing dependency issues
development
Use when implementing or debugging ANY network request, API call, or data fetching. Covers fetch API, React Query, SWR, error handling, caching, offline support, and Expo Router data loaders (`useLoaderData`).
tools
`@expo/ui/swift-ui` package lets you use SwiftUI Views and modifiers in your app.