Marion JS SDK

A lightweight JavaScript helper library for applications that need to talk to the Marion civic chain. The focus is simplicity: plain ES modules, zero build tooling, and just enough structure to cover identity, vendors, properties, and governance as we iterate.

Quick Start

cd marion-sdk
npm install
npm test

import { createMarionSdk } from "marion-sdk";

const sdk = await createMarionSdk({ network: "hardhat" });
const vendor = await sdk.vendors.getVendor("0x1234...abcd");

console.log(vendor);

By default the SDK reads deployment manifests from ../deployments/<network>.manifest.json. Override this by passing manifestDir or manifestPath to createMarionSdk.

Generating manifests automatically

Ship your contracts and ABIs, then run the built-in CLI to stitch together a Marion manifest that downstream apps (including this SDK) can consume:

npx marion-manifest \
  --network localhost \
  --deploymentsDir ./deployments \
  --addresses ./deployments/localhost.addresses.json \
  --force

Where localhost.addresses.json looks like:

{
  "chainId": 31337,
  "network": "localhost",
  "deployer": "0x1234...dead",
  "contracts": {
    "CityRegistry": "0xabc...",
    "ProjectController": "0xdef...",
    "ProposalRegistry": "0x456..."
  }
}

If you store addresses at deployments/<network>.addresses.json or deployments/<network>/addresses.json the CLI discovers them automatically—perfect for new teams installing marion-sdk via npm without custom scripting.

Structure

src/
  index.js          // entry point – wires the context + modules
  context.js        // viem client factory + manifest loader
  manifest.js       // lightweight manifest reader/normalizer
  errors.js         // shared error helpers
  modules/
    vendors.js      // first fully wired module
    identity.js     // scaffolded, ready for implementation
    governance.js   // scaffolded
    properties.js   // scaffolded
tests/
  manifest.test.js  // exercises the manifest loader against local files
  vendors.test.js   // verifies vendor reads/writes (with stubs)

Scripts

• npm test – runs the Node built-in test runner (no extra harness needed).
• npm run lint – lint the sources with ESLint (config TBD).

Next Steps

1. Flesh out the remaining modules using the deployed contract ABIs.
2. Add integration tests that spin up Anvil/Hardhat, seed the chain, and exercise full flows.
3. Publish the package (or pack tarballs) once we’re satisfied with the coverage.

See ../sdk-test-plan.md for the roadmap covering modules, tests, and automation.