fix(pg-node): clean up stale Node 20 references and README style#48
Conversation
Follow-up to dobby's review on the (already-merged) #46: - Root README and pg-node/src/config.mjs still referenced "Node 20.6+" after the engines bump to >=22 in #46's chore commit. - pg-node/src/config.mjs comment referenced `--env-file=` but the npm scripts use `--env-file-if-exists`. - pg-node/README "Two modes" list used the inline-header + em-dash pattern flagged by writing-rules; converted to a small table. - Trimmed a few stylistic em-dashes (lead paragraph, prerequisites, staging note, SDK-mapping paragraph). Kept the bold "does not actually deliver notification emails" callout — that one is load-bearing. No behaviour change; verified with `node --check` on all .mjs files and a live `npm run upload` to staging (UUID 6e22edaf-…).
![dobby-coder[bot]](https://avatars.githubusercontent.com/in/3365457?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code review
Tiny doc-cleanup PR (3 files, +13/-11) that does largely what the description claims: bumps a stale Node 20.6+ string in the root README to 22+, fixes a config.mjs comment that referenced an outdated --env-file= flag, and trims em-dashes from pg-node/README.md. Technical claims hold up (engines.node is >=22, npm scripts use --env-file-if-exists, node --check passes on all three .mjs files).
However, the PR's stated goal — eliminating the writing-rules #48 inline-header + sentence pattern — is only half-done: pg-node/README.md:18 still uses exactly that pattern, just with a comma instead of an em-dash, which is a syntactic swap rather than a structural fix. The new Two modes table is fine but the rows are very wide and slightly less precise than the prior copy. One newly-introduced comma on line 14 is grammatically wrong. None of these block; logging post-merge so the next style pass picks them up.
No automated tests exist in the repo so the only verification is a manual live upload, which the description records.
Rule compliance
Checked against ~12 rules from dobby-memory/rules/. Most don't apply (workflow/bot/board rules). Notable findings:
- writing-rules.md — PARTIAL. The PR's main stated target (rule #48 inline-header + sentence) survives at
pg-node/README.md:18. TheDrop-in starting pointphrase on line 3 still pattern-matches rule #33 (press-release voice). Most em-dashes (#40) were removed correctly elsewhere. - standardized-readmes.md — NOT_APPLICABLE.
pg-node/README.mdis an example sub-project, not a top-level repo README; the logo / Development / Releasing / License scaffold doesn't apply here. - conventional-commit-pr-titles.md — OK.
fix(pg-node): …is a valid type+scope.docs:would be arguably more accurate butfix:for stale-doc correction is acceptable. - tests-required-on-fixes.md — OK (doc/comment-only fix, repo has no test infra). Possible enhancement: a CI step that diffs the README's claimed Node version against
package.jsonengines.nodewould prevent exactly this PR's reason-for-being from recurring on the next bump. - never-self-merge-prs.md / no-merge-acknowledgement-comments.md — OK. Merged by rubenhensen (the maintainer, not Dobby); no post-merge ack comments.
- docs-drift-check.md — Follow-up worth opening.
postguard-docs/docs/repos/postguard-js.mdstill says "Node.js 20+" in its Development Prerequisites section — the upstream SDK is onengines.node: >=22and this PR makes the example consistent, but the canonical docs are now the lagging copy. Worth a small postguard-docs PR. - take-terse-feedback-literally.md, promised-vs-delivered.md, typo-sweep-template.md, cross-repo-link-format.md, report-format-rules.md — NOT_APPLICABLE or NO violation.
No blocking rule violations. Inline notes below for the writing-rules residue.
| ## Prerequisites | ||
|
|
||
| - **Node.js 22+** — matches `@e4a/pg-js`'s `engines.node`. The SDK also supports Bun and Deno; the same encryption code in `src/encryption.mjs` works there too. | ||
| - **Node.js 22+**, matching `@e4a/pg-js`'s `engines.node`. The SDK also supports Bun and Deno; the same encryption code in `src/encryption.mjs` works there too. |
There was a problem hiding this comment.
[Code review + Rule: writing-rules #48] PR claims to eliminate the writing-rules #48 inline-header + sentence list pattern, but this line still has it: - **Node.js 22+**, matching …. Swapping the em-dash for a comma keeps the exact structural pattern (bold inline header functioning as a sub-title for the sentence after it). To fix #48 properly, drop the bold inline header or move it into a sentence-level subject — e.g. Node.js 22+ (matches @e4a/pg-js's engines.node). The SDK also supports Bun and Deno; ….
| | Upload-only | `npm run upload` | Same encryption and upload, but silent. Cryptify returns a UUID you can distribute through some other channel. | | ||
|
|
||
| Files come from `PG_INPUT_FILES` (comma-separated paths) or two in-memory demo files if that is unset. | ||
| Files come from `PG_INPUT_FILES` (comma-separated paths), or two in-memory demo files if that is unset. |
There was a problem hiding this comment.
[Code review] Diff inserts a comma here: Files come from PG_INPUT_FILES (comma-separated paths), or two in-memory demo files if that is unset. This coordinates two simple objects of the same verb (come from X or Y), so the comma before or is incorrect under standard prose rules — it reads as a stray pause. The pre-diff version (no comma) was right. Either revert the comma or restructure into two sentences.
| ## What it does | ||
|
|
||
| Two modes, selected by the script flag: | ||
| Two modes, selected by an npm script: |
There was a problem hiding this comment.
[Code review] Wording changed from selected by the script flag to selected by an npm script. The npm scripts are thin wrappers that pass --upload-only (see pg-node/package.json + pg-node/index.mjs:28) — i.e. the script flag is the actual mode-selector and the npm script just sets it. The original phrasing was more accurate; the new one papers over the mechanism. If you don't want to mention the flag, at least pick a phrasing that doesn't imply two distinct binaries (e.g. Two modes, one per npm script:).
| # pg-node: PostGuard Node.js example | ||
|
|
||
| Node.js example demonstrating how to use the [@e4a/pg-js](https://www.npmjs.com/package/@e4a/pg-js) SDK from a server runtime. Mirrors the [pg-sveltekit](../pg-sveltekit) example's "Informatierijk notificeren" flow (citizen + organisation recipients) but as a CLI script — drop-in starting point for backend integrations. | ||
| Node.js example demonstrating how to use the [@e4a/pg-js](https://www.npmjs.com/package/@e4a/pg-js) SDK from a server runtime. Mirrors the [pg-sveltekit](../pg-sveltekit) example's "Informatierijk notificeren" flow (citizen + organisation recipients) as a CLI script. Drop-in starting point for backend integrations. |
There was a problem hiding this comment.
[Code review + Rule: writing-rules #33] Drop-in starting point for backend integrations is borderline promotional and pattern-matches what writing-rules calls AI-slop (press-release voice / vague aspirational uplift). Not banned and pre-existing from #46, but the PR touched this line — replacement candidate: Use as a starting point when integrating PostGuard from a backend.
| 2. **Upload-only** (`npm run upload`) — same encryption + upload, but silent. Cryptify returns a UUID you can distribute through some other channel. | ||
| | Mode | Command | What it does | | ||
| | ----------- | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | Send | `npm run send` | Encrypts the input files for a citizen (exact email) and an organisation (email domain), uploads to Cryptify, and asks Cryptify to email each recipient. | |
There was a problem hiding this comment.
[Code review] Two-row Markdown table whose content rows are 220–250 chars wide. Renders fine on GitHub but the raw markdown is awkward to read and edit (and the existing Configuration table further down doesn't need to be this wide). Consider either dropping back to a list (without the inline-header pattern) or keeping commands+modes as one column and moving the descriptions to prose.
| // Env-driven config. Run with `node --env-file=.env index.mjs` to load | ||
| // from .env (Node 20.6+). Mirrors pg-sveltekit's config.ts. | ||
| // Env-driven config. `.env` is loaded automatically by the npm scripts | ||
| // via Node's `--env-file-if-exists`. Mirrors pg-sveltekit's config.ts. |
There was a problem hiding this comment.
[Code review] Comment now says .env is loaded automatically by the npm scripts via Node's --env-file-if-exists. Accurate, but --env-file-if-exists requires Node 21.7+ — fine because engines.node is >=22, but a future reader who runs node src/config.mjs directly under an older Node will be confused. Either leave alone (current state is acceptable) or add a one-clause note that the flag is wired in package.json and only matters when you use the npm scripts.
1 participant
Summary
Follow-up to dobby's review on the (already-merged) #46. Addresses the inline comments that landed after the merge — all doc/comment cleanups, no behaviour change.
What changed
Stale
Node 20.6+references after the engines bump:README.md:30said "Requires Node.js 20.6+" → now "Node.js 22+", matchingpg-node/package.json'sengines.node.pg-node/src/config.mjs:2comment said "(Node 20.6+)" and referencednode --env-file=.env→ now matches the actual setup (npm scripts wire--env-file-if-existsthemselves).pg-node/README.mdstyle cleanup fromwriting-rules:Observations from dobby that need no fix:
Test plan