|
| 1 | +# NicTool Monorepo Copilot Instructions |
| 2 | + |
| 3 | +## Purpose |
| 4 | + |
| 5 | +This repository is a multi-package NicTool workspace that includes: |
| 6 | + |
| 7 | +- A Node.js API service (`api`) that talks to MySQL and uses JWT auth. |
| 8 | +- Shared DNS/domain libraries (`dns-resource-record`, `dns-zone`, `dns-nameserver`, `validate`). |
| 9 | +- A web client (`client`). |
| 10 | +- A legacy Perl NicTool stack (`NicTool`). |
| 11 | + |
| 12 | +When making changes, treat this as a set of related but independently runnable packages. |
| 13 | + |
| 14 | +## How The Pieces Fit Together |
| 15 | + |
| 16 | +High-level dependency flow: |
| 17 | + |
| 18 | +1. `dns-resource-record`: record-level parsing/validation/conversion. |
| 19 | +2. `dns-zone`: zone-level import/export and zone-rule validation, built on `dns-resource-record`. |
| 20 | +3. `dns-nameserver`: nameserver config parsers, built on `dns-zone`. |
| 21 | +4. `validate`: NicTool object schema validation (group/user/zone/etc). |
| 22 | +5. `api`: HTTP API service using `@nictool/validate` and `@nictool/dns-resource-record`, plus MySQL. |
| 23 | +6. `client`: browser UI that consumes API behavior. |
| 24 | +7. `NicTool`: legacy server/client implementation (Perl stack). |
| 25 | + |
| 26 | +## Monorepo Working Rules |
| 27 | + |
| 28 | +- There is no single root `package.json` for all packages. Run install/test/lint inside the package you are changing. |
| 29 | +- Keep changes scoped. If you need to change API behavior, update the API package and its tests, but do not make sweeping changes to shared libraries unless necessary. |
| 30 | +- Respect each package's existing module system: |
| 31 | + - ESM packages exist (`api`, `dns-resource-record`, `dns-zone`, `dns-nameserver`, `client`). |
| 32 | + - Convert CommonJS in (`validate`) to ESM |
| 33 | +- Preserve package-local formatting/lint style. Do not run sweeping repo-wide formatting. |
| 34 | + |
| 35 | +## API Package Guidance (`api`) |
| 36 | + |
| 37 | +- Service entry: `server.js` calls `routes/index.js` startup. |
| 38 | +- Routing lives in `routes/*.js`; data access and business logic live in `lib/*.js`. |
| 39 | +- Route validation schemas come from `@nictool/validate`. |
| 40 | +- Config is YAML-driven via `conf.d/*.yml` and loaded through `lib/config.js`. |
| 41 | +- Tests are `node --test`, orchestrated by `test.sh`. |
| 42 | +- `test.sh` sets up and tears down DB fixtures; keep tests compatible with that flow. |
| 43 | + |
| 44 | +If you change an API route or payload shape: |
| 45 | + |
| 46 | +1. Update route handler in `routes/`. |
| 47 | +2. Update related logic in `lib/` as needed. |
| 48 | +3. Update route/lib tests (`routes/*.test.js`, `lib/*.test.js`). |
| 49 | +4. Keep validation contracts in sync with `@nictool/validate`. |
| 50 | + |
| 51 | +## Database And Config Safety |
| 52 | + |
| 53 | +- API tests expect a local MySQL instance and schema initialization from `api/sql`. |
| 54 | +- Never introduce real secrets. |
| 55 | +- Prefer environment overrides or test/dev config blocks instead of hardcoding credentials. |
| 56 | +- Do not commit local machine paths, ad hoc cert material, or one-off debug config changes. |
| 57 | + |
| 58 | +## Shared Library Guidance |
| 59 | + |
| 60 | +### `validate` |
| 61 | + |
| 62 | +- Contains object/schema validation used by API routes. |
| 63 | +- CommonJS exports (`module.exports` pattern). |
| 64 | +- Tests run with `node --test`. |
| 65 | + |
| 66 | +### `dns-resource-record` |
| 67 | + |
| 68 | +- Record-level parser/validator/import/export library. |
| 69 | +- Focus on RFC-compliant RR behavior and conversion fidelity. |
| 70 | +- Tests use Mocha. |
| 71 | + |
| 72 | +### `dns-zone` |
| 73 | + |
| 74 | +- Zone-level import/export and coexistence rules for records. |
| 75 | +- Uses `dns-resource-record` underneath. |
| 76 | +- Tests use Mocha. |
| 77 | + |
| 78 | +### `dns-nameserver` |
| 79 | + |
| 80 | +- Parses nameserver config formats (bind, knot, maradns, nsd, tinydns). |
| 81 | +- Uses `dns-zone`. |
| 82 | +- Tests use Mocha. |
| 83 | + |
| 84 | +## Client Guidance |
| 85 | + |
| 86 | +- `client`: Vite-based web UI with Bootstrap/Sass. |
| 87 | +- Keep API contract assumptions aligned with current API responses. |
| 88 | +- Avoid changing API payload formats only to satisfy UI code unless requested. |
| 89 | + |
| 90 | +## Legacy NicTool (`NicTool`) |
| 91 | + |
| 92 | +- This is the legacy Perl implementation and has different conventions/tooling. |
| 93 | +- Do not apply Node package assumptions in this tree. |
| 94 | +- Make minimal, isolated changes when touching this area. |
| 95 | + |
| 96 | +## Test And Lint Commands By Package |
| 97 | + |
| 98 | +- `api` |
| 99 | + - `npm test` |
| 100 | + - `npm run lint` |
| 101 | + - `npm run prettier` |
| 102 | +- `validate` |
| 103 | + - `npm test` |
| 104 | + - `npm run lint` |
| 105 | + - `npm run prettier` |
| 106 | +- `dns-resource-record` |
| 107 | + - `npm test` |
| 108 | + - `npm run lint` |
| 109 | + - `npm run prettier` |
| 110 | +- `dns-zone` |
| 111 | + - `npm test` |
| 112 | + - `npm run lint` |
| 113 | + - `npm run prettier` |
| 114 | +- `dns-nameserver` |
| 115 | + - `npm test` |
| 116 | + - `npm run lint` |
| 117 | +- `client` |
| 118 | + - `npm run develop` (or `npm run start`) |
| 119 | + - `npm run build` |
| 120 | + - `npm run lint` |
| 121 | + - `npm run prettier` |
| 122 | + |
| 123 | +Run the smallest relevant test/lint set for changed files first, then broaden if needed. |
| 124 | + |
| 125 | +## Change Style Expectations |
| 126 | + |
| 127 | +- Keep patches small and targeted. |
| 128 | +- Preserve existing naming and file layout. |
| 129 | +- Add or update tests for behavior changes. |
| 130 | +- Avoid dependency churn unless required for the task. |
| 131 | +- Prefer explicit error handling and clear return shapes in API code. |
| 132 | + |
| 133 | +## Commit Hygiene |
| 134 | + |
| 135 | +- Keep commits focused by package or concern. |
| 136 | +- Include a brief rationale in commit messages when behavior changes. |
| 137 | +- Mention cross-package impact explicitly when a change in one package affects another. |
0 commit comments