@quicktalog/common 1.51.0 → 1.53.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md ADDED
@@ -0,0 +1,113 @@
1
+ # @quicktalog/common
2
+
3
+ Shared TypeScript building blocks for the Quicktalog applications — published to npm and installed
4
+ by every service that needs to agree on the same types, constants, helpers, and database schema.
5
+
6
+ The goal is a single source of truth. When a catalogue gains a field or a pricing tier changes, it
7
+ changes here once, gets published, and every consumer picks it up by bumping a version rather than
8
+ re-declaring the shape locally and drifting out of sync.
9
+
10
+ ## Installation
11
+
12
+ ```bash
13
+ npm install @quicktalog/common
14
+ ```
15
+
16
+ ```ts
17
+ import { tiers, defaultCatalogueData, generateUniqueSlug, schema } from "@quicktalog/common";
18
+ ```
19
+
20
+ Everything is re-exported from the package root, so there are no deep import paths to remember.
21
+
22
+ ## What's inside
23
+
24
+ The package is ESM-only (`"type": "module"`) and ships compiled JavaScript plus `.d.ts`
25
+ declarations from `dist/`. Source lives in `src/` and is organised into four groups:
26
+
27
+ | Group | Path | Contents |
28
+ | --- | --- | --- |
29
+ | **Types** | `src/types/` | Domain models and unions — `Catalogue`, `ContentBlockType`, `Status`, `ThemeType`, `LimitType`, and friends |
30
+ | **Constants** | `src/constants/` | Shared values — `themes`, `layouts`, `tiers`, `BUSINESS_TYPES`, `defaultCatalogueData` |
31
+ | **Helpers** | `src/helpers/` | Small utilities such as `generateUniqueSlug` and `fetchImageFromUnsplash` |
32
+ | **Drizzle** | `src/drizzle/` | The Postgres schema, exported as a `schema` namespace, plus generated relations |
33
+
34
+ The Drizzle schema is **generated, not hand-written**. `src/drizzle/migrations/schema.ts` is
35
+ produced by `drizzle-kit pull`, which introspects the live Postgres database described by
36
+ `drizzle.config.ts`. Treat the database as authoritative and regenerate rather than editing those
37
+ files directly.
38
+
39
+ ## Local development
40
+
41
+ ```bash
42
+ npm install # also installs the git hooks via the prepare script
43
+ npm run build # tsc -> dist/
44
+ ```
45
+
46
+ ### Git hooks
47
+
48
+ A single Husky hook runs on commit:
49
+
50
+ ```
51
+ .husky/pre-commit
52
+ ├── npx drizzle-kit pull (only when a real DATABASE_URL is available)
53
+ └── npm run build
54
+ ```
55
+
56
+ The drizzle step is guarded. It looks for `DATABASE_URL` in the environment, falls back to `.env`,
57
+ and runs only if the value actually looks like a connection string. Without one it prints a skip
58
+ notice and moves on, so fresh clones and CI can commit without a database. The build always runs,
59
+ so a commit that does not typecheck cannot be created.
60
+
61
+ There is deliberately **no pre-push hook**. Versioning is explicit — see below.
62
+
63
+ > **Note:** when the drizzle step does run, it rewrites files under `src/drizzle/migrations/`
64
+ > *after* staging has already happened. Those regenerated files land in your working tree unstaged;
65
+ > review and commit them yourself.
66
+
67
+ ## Release workflow
68
+
69
+ Publishing is driven entirely by the version in `package.json`. Pushing to `main` is what triggers
70
+ CI, but only a **new** version actually publishes.
71
+
72
+ ```
73
+ npm run release
74
+ ├── npm version minor -> bumps package.json, commits it, tags it
75
+ │ (the commit message is just the version, e.g. "1.53.0")
76
+ └── git push --follow-tags -> pushes the commit and its tag
77
+ ```
78
+
79
+ Use `npm run release:patch` or `npm run release:major` for the other bump types. `--follow-tags`
80
+ matters: a plain `git push` leaves the tag stranded locally.
81
+
82
+ Because the bump lives *inside* the commit being pushed, the version CI sees is always the version
83
+ you intended to ship. The commit message being the bare version string is also why the GitHub
84
+ Actions run shows up named after the release.
85
+
86
+ ### What CI does
87
+
88
+ `.github/workflows/publish.yaml` runs on every push to `main`:
89
+
90
+ 1. Checkout, set up Node 22, upgrade npm for OIDC support
91
+ 2. `npm ci`
92
+ 3. `npm run build`
93
+ 4. **Check the registry** for the current `name@version`
94
+ 5. `npm publish --access public` — only if that version does not already exist
95
+
96
+ Step 4 is what keeps ordinary commits green. A docs or config push builds and verifies as usual,
97
+ then skips publishing instead of failing on a version that is already taken. The job summary states
98
+ which path it took, so a green run never leaves you guessing whether it shipped.
99
+
100
+ ### Authentication
101
+
102
+ There is no npm token. Publishing uses **OIDC trusted publishing** — GitHub Actions proves its
103
+ identity to npm directly, and npm attaches a signed [provenance](https://docs.npmjs.com/generating-provenance-statements)
104
+ statement to each release.
105
+
106
+ This is why `package.json` must carry a `repository` field pointing at this repo: npm validates the
107
+ provenance bundle against it and rejects the publish with `E422` if the two disagree.
108
+
109
+ ## Conventions
110
+
111
+ - **Never edit `package.json` version by hand** — use the release scripts so the tag and commit stay consistent
112
+ - **Never hand-edit the generated Drizzle schema** — change the database and re-pull
113
+ - `dist/` is gitignored and built by CI; only `src/` is tracked
@@ -26,6 +26,7 @@ export type BaseContentBlock = {
26
26
  };
27
27
  export type DividerBlock = BaseContentBlock & {
28
28
  type: "divider";
29
+ name?: string;
29
30
  spacing: number;
30
31
  border?: {
31
32
  isEnabled: boolean;
@@ -50,14 +51,17 @@ export type ContainerBlock = BaseContentBlock & {
50
51
  };
51
52
  export type EmbeddingBlock = BaseContentBlock & {
52
53
  type: "embedding";
54
+ name?: string;
53
55
  code: string;
54
56
  };
55
57
  export type CustomCodeBlock = BaseContentBlock & {
56
58
  type: "custom_code";
59
+ name?: string;
57
60
  code: string;
58
61
  };
59
62
  export type TextBlock = BaseContentBlock & {
60
63
  type: "text";
64
+ name?: string;
61
65
  content: string;
62
66
  };
63
67
  export type ContentBlock = CategoryBlock | ContainerBlock | EmbeddingBlock | CustomCodeBlock | TextBlock | DividerBlock;
package/package.json CHANGED
@@ -1,6 +1,14 @@
1
1
  {
2
2
  "name": "@quicktalog/common",
3
- "version": "1.51.0",
3
+ "version": "1.53.0",
4
+ "repository": {
5
+ "type": "git",
6
+ "url": "git+https://github.com/nikolamirilo/quicktalog-packages.git"
7
+ },
8
+ "homepage": "https://github.com/nikolamirilo/quicktalog-packages#readme",
9
+ "bugs": {
10
+ "url": "https://github.com/nikolamirilo/quicktalog-packages/issues"
11
+ },
4
12
  "type": "module",
5
13
  "main": "dist/index.js",
6
14
  "types": "dist/index.d.ts",
@@ -9,6 +17,9 @@
9
17
  ],
10
18
  "scripts": {
11
19
  "build": "tsc",
20
+ "release": "npm version minor && git push --follow-tags",
21
+ "release:patch": "npm version patch && git push --follow-tags",
22
+ "release:major": "npm version major && git push --follow-tags",
12
23
  "prepare": "husky"
13
24
  },
14
25
  "devDependencies": {