@aintela/chat 0.2.16 → 0.2.17

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 CHANGED
@@ -1,17 +1,21 @@
1
- # @envision/aichat
1
+ # @aintela/chat
2
2
 
3
3
  Embeddable AI chat component built on a WebSocket agent gateway. This repo
4
- is the new home for what was previously `packages/library/src/components/AiChat/`
5
- in `envision-abi` — extracted into a standalone package so it can be
6
- consumed as a real library (built, versioned, peer-dep'd) instead of via
7
- in-tree source aliasing.
4
+ is the standalone home for what was previously
5
+ `packages/library/src/components/AiChat/` in `envision-abi` — extracted into a
6
+ real library (built, versioned, peer-dep'd) instead of in-tree source aliasing,
7
+ and published to the public npm registry.
8
+
9
+ > **Name history:** `@envision/aichat` → `@aia/chat` → **`@aintela/chat`** (the
10
+ > npm `@aia` org was taken). Always install and import `@aintela/chat`.
8
11
 
9
12
  ## Layout
10
13
 
11
- This repo is the published package (`@envision/aichat`) at its root:
14
+ This repo is the published package (`@aintela/chat`) at its root:
12
15
 
13
16
  - `src/`, `package.json`, `vite.config.ts`, `tsconfig.json` — library source + config
14
- - `dist/` — built output, gitignored (rebuilt on every install via `prepare`)
17
+ - `dist/` — built output, gitignored; **shipped in the npm tarball** (built on
18
+ `prepack`/`prepare` via `vite build`)
15
19
  - `examples/demo/` — Vite + React SPA that exercises the library against a fake
16
20
  agent gateway, with an option to point at a real WSServer
17
21
 
@@ -22,9 +26,9 @@ npm install
22
26
  cd examples/demo && npm install && npm run dev # http://localhost:5174
23
27
  ```
24
28
 
25
- The demo aliases `@envision/aichat` to the root `src/` during development so
26
- HMR works across the package boundary. To validate the built bundle the way
27
- a real consumer would:
29
+ The demo aliases the package to the root `src/` during development so HMR works
30
+ across the package boundary. To validate the built bundle the way a real
31
+ consumer would:
28
32
 
29
33
  ```bash
30
34
  npm run build
@@ -33,19 +37,27 @@ npm run build
33
37
 
34
38
  ## Consuming
35
39
 
36
- Consumers install via a git URL no public registry. Pin to a tag for
37
- reproducibility; npm's `prepare` script runs `vite build` so the consumer's
38
- `node_modules/@envision/aichat/dist/` is populated automatically.
40
+ `@aintela/chat` is published to the **public npm registry** install it like
41
+ any package and pin a normal semver range:
42
+
43
+ ```bash
44
+ npm install @aintela/chat
45
+ ```
39
46
 
40
47
  ```json
41
48
  {
42
49
  "dependencies": {
43
- "@envision/aichat": "github:envision-tecnologia/aichat#v0.1.1"
50
+ "@aintela/chat": "^0.2.16"
44
51
  }
45
52
  }
46
53
  ```
47
54
 
48
- (`github:owner/repo#ref` is npm's shorthand for `git+ssh://git@github.com/owner/repo.git#ref` both forms work; npm normalizes to the shorthand on install.)
55
+ The tarball ships the prebuilt `dist/` (see the `files` field in `package.json`),
56
+ so consumers don't build anything on install.
57
+
58
+ Subpath entry points are exported for focused imports: `@aintela/chat` (root),
59
+ plus `@aintela/chat/models`, `/services`, `/components`, `/hooks`, `/utils`,
60
+ `/interfaces`, and the stylesheet `@aintela/chat/style.css`.
49
61
 
50
62
  Every peer in `peerDependencies` must be installed by the consumer at a
51
63
  compatible version — that's how shared singletons (React, MUI ThemeContext,
@@ -77,10 +89,11 @@ Open `coverage/index.html` in a browser for the drill-down report.
77
89
 
78
90
  ## Releasing
79
91
 
80
- Cut a release whenever you ship a behavior change (bugfix, new prop,
81
- breaking API change). Tags are the source of truth consumers pin to
82
- them, so the tag-on-`main` workflow is intentional discipline, not
83
- overhead.
92
+ Cut a release whenever you ship a behavior change (bugfix, new prop, breaking
93
+ API change). Publishing is **tag-driven**: pushing a `v<semver>` tag runs the
94
+ `publish-aia-chat.yml` workflow, which `npm publish`es to the public npm registry
95
+ via npm **Trusted Publishing** (OIDC — no stored token) with build provenance.
96
+ `access: public` comes from `package.json`'s `publishConfig`.
84
97
 
85
98
  ### 1. Bump + commit + tag + push
86
99
 
@@ -88,8 +101,8 @@ From the repo root, after the change is committed on `main`:
88
101
 
89
102
  ```bash
90
103
  # 1. bump version in package.json (semver: patch / minor / major)
91
- npm version patch --no-git-tag-version # 0.1.1 → 0.1.2 (bugfix)
92
- # npm version minor --no-git-tag-version # 0.1.x → 0.2.0 (new prop / feature)
104
+ npm version patch --no-git-tag-version # 0.2.16 → 0.2.17 (bugfix)
105
+ # npm version minor --no-git-tag-version # 0.2.x → 0.3.0 (new prop / feature)
93
106
  # npm version major --no-git-tag-version # 0.x.y → 1.0.0 (breaking)
94
107
 
95
108
  # 2. commit the bump
@@ -101,38 +114,40 @@ git tag -a vX.Y.Z -m "vX.Y.Z — <short release note>"
101
114
  git push origin main vX.Y.Z
102
115
  ```
103
116
 
104
- `--no-git-tag-version` on `npm version` is deliberate: it bumps
105
- `package.json` without creating its own commit/tag, so you control the
106
- commit message and tag annotation explicitly (npm's defaults are
107
- ambiguous when the bump rides alongside the substantive change).
117
+ The pushed `vX.Y.Z` tag triggers CI (`npm ci` + `npm publish --provenance`). The
118
+ tag version and the `package.json` version must match. You can also run the
119
+ workflow manually (**workflow_dispatch**) to publish whatever version is currently
120
+ in `package.json`.
121
+
122
+ `--no-git-tag-version` on `npm version` is deliberate: it bumps `package.json`
123
+ without creating its own commit/tag, so you control the commit message and tag
124
+ annotation explicitly (npm's defaults are ambiguous when the bump rides alongside
125
+ the substantive change).
126
+
127
+ > **One-time setup** (already done, noted here for recovery): on npmjs.com, the
128
+ > `@aintela` org / package registers a Trusted Publisher for repo
129
+ > `envision-tecnologia/aichat`, workflow `publish-aia-chat.yml`. A token fallback
130
+ > (`NPM_TOKEN` secret → `NODE_AUTH_TOKEN`) is stubbed in the workflow if OIDC ever
131
+ > needs to be bypassed.
108
132
 
109
133
  ### 2. Update consumers
110
134
 
111
- Each consumer pins the dep to a specific tag in its `package.json`:
135
+ Each consumer bumps its semver range (or just reinstalls, if the existing range
136
+ already covers the new version):
112
137
 
113
138
  ```diff
114
- - "@envision/aichat": "github:envision-tecnologia/aichat#v0.1.1",
115
- + "@envision/aichat": "github:envision-tecnologia/aichat#v0.1.2",
139
+ - "@aintela/chat": "^0.2.16",
140
+ + "@aintela/chat": "^0.2.17",
116
141
  ```
117
142
 
118
- Then in the consumer's repo:
119
-
120
143
  ```bash
121
- npm install @envision/aichat
122
- # dashboard-app currently needs --legacy-peer-deps because of an
123
- # unrelated transitive peer conflict (MUI + pigment-css). Drop the flag
124
- # once that's resolved.
144
+ npm install @aintela/chat
125
145
  ```
126
146
 
127
- npm re-clones the package at the new tag, runs the package's `prepare`
128
- script (which runs `vite build`), and updates the consumer's lockfile
129
- with the new commit SHA — so subsequent installs on other machines pull
130
- the exact same code, even if the tag is later moved (don't move tags).
131
-
132
147
  ### Quick smoke-test before tagging
133
148
 
134
- `v0.1.1` shipped with a part-eventType bug that the demo surfaced
135
- within seconds. Before pushing a tag, give it a minute:
149
+ `v0.1.1` shipped with a part-eventType bug that the demo surfaced within seconds.
150
+ Before pushing a tag, give it a minute:
136
151
 
137
152
  ```bash
138
153
  npm run build && npm run typecheck # at repo root