@hydranium/protocol 1.0.0-next.25 → 1.0.0-next.28

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.
Files changed (44) hide show
  1. package/lib/client/data-port.d.ts +10 -3
  2. package/lib/client/data-port.d.ts.map +1 -1
  3. package/lib/client/data-session.d.ts +8 -0
  4. package/lib/client/data-session.d.ts.map +1 -1
  5. package/lib/client/data-session.js +12 -3
  6. package/lib/client/data-session.js.map +1 -1
  7. package/lib/client/message-relay.d.ts +8 -2
  8. package/lib/client/message-relay.d.ts.map +1 -1
  9. package/lib/client/message-relay.js +10 -4
  10. package/lib/client/message-relay.js.map +1 -1
  11. package/lib/errors.d.ts +11 -1
  12. package/lib/errors.d.ts.map +1 -1
  13. package/lib/errors.js +16 -6
  14. package/lib/errors.js.map +1 -1
  15. package/lib/index.d.ts +1 -0
  16. package/lib/index.d.ts.map +1 -1
  17. package/lib/index.js +4 -0
  18. package/lib/index.js.map +1 -1
  19. package/lib/messages/index.d.ts +28 -0
  20. package/lib/messages/index.d.ts.map +1 -0
  21. package/lib/messages/index.js +52 -0
  22. package/lib/messages/index.js.map +1 -0
  23. package/lib/messages/primitives.d.ts +135 -0
  24. package/lib/messages/primitives.d.ts.map +1 -0
  25. package/lib/messages/primitives.js +138 -0
  26. package/lib/messages/primitives.js.map +1 -0
  27. package/lib/testing/data-doubles.d.ts +5 -3
  28. package/lib/testing/data-doubles.d.ts.map +1 -1
  29. package/lib/testing/data-doubles.js +2 -2
  30. package/lib/testing/data-doubles.js.map +1 -1
  31. package/lib/transfer-diagnostic.d.ts +33 -0
  32. package/lib/transfer-diagnostic.d.ts.map +1 -1
  33. package/lib/transfer-diagnostic.js +23 -0
  34. package/lib/transfer-diagnostic.js.map +1 -1
  35. package/package.json +9 -1
  36. package/src/client/data-port.ts +10 -3
  37. package/src/client/data-session.ts +21 -2
  38. package/src/client/message-relay.ts +28 -6
  39. package/src/errors.ts +20 -6
  40. package/src/index.ts +4 -0
  41. package/src/messages/index.ts +35 -0
  42. package/src/messages/primitives.ts +209 -0
  43. package/src/testing/data-doubles.ts +8 -6
  44. package/src/transfer-diagnostic.ts +40 -0
@@ -0,0 +1,209 @@
1
+ /********************************************************************************
2
+ * Copyright (c) 2026 CrossBreeze, EclipseSource and others.
3
+ *
4
+ * This program and the accompanying materials are made available under the
5
+ * terms of the MIT License which is available in the project root.
6
+ *
7
+ * SPDX-License-Identifier: MIT
8
+ ********************************************************************************/
9
+
10
+ import { ResponseError } from 'vscode-jsonrpc';
11
+
12
+ /**
13
+ * The framework externalizes user-facing strings and never translates them: it
14
+ * holds no locale, so it cannot know what the reading user reads. Every such
15
+ * string carries a stable code beside its English text, and whoever owns the
16
+ * surface renders it. A framework-held locale would give one toast two
17
+ * authorities — an adopter sentence in one language wrapping a framework clause
18
+ * in another.
19
+ *
20
+ * Codes are `hydranium/<unscoped-package>/<name>`. The package segment locates
21
+ * the declaration, so a message is declared in the package that raises it and a
22
+ * code never names a package it does not live in. `.` and `:` are forbidden in a
23
+ * segment: they are i18next's default key and namespace separators, where either
24
+ * silently becomes a nested lookup that misses.
25
+ */
26
+ export type MessageParams = Readonly<Record<string, string | number>>;
27
+
28
+ type Placeholder<S extends string> = S extends `${string}{${infer Name}}${infer Rest}` ? Name | Placeholder<Rest> : never;
29
+
30
+ export type ParamsOf<S extends string> = [Placeholder<S>] extends [never]
31
+ ? Record<never, never>
32
+ : Readonly<Record<Placeholder<S>, string | number>>;
33
+
34
+ /** Required exactly when the text has placeholders, absent when it does not. */
35
+ export type ParamsArg<S extends string> = [Placeholder<S>] extends [never] ? [] : [params: ParamsOf<S>];
36
+
37
+ /**
38
+ * Rejects a text argument already widened to `string`. Load-bearing rather than
39
+ * defensive: the whole compile-time guarantee is conditional on `S` inferring a
40
+ * literal, and for a concatenated or pre-widened text the placeholder set
41
+ * silently becomes empty, `format()` accepts no arguments, and the missing
42
+ * substitution surfaces only at runtime.
43
+ */
44
+ export type LiteralText<S extends string> = string extends S ? never : S;
45
+
46
+ export interface MessageDefinition<S extends string> {
47
+ readonly code: string;
48
+ readonly text: S;
49
+ format(...args: ParamsArg<S>): string;
50
+ }
51
+
52
+ /**
53
+ * Declare a message. Placeholder names are inferred from `text` rather than
54
+ * declared again in a type argument: a second spelling of every name is the
55
+ * repetition that drifts, since adding a placeholder to the sentence and not to
56
+ * the type compiles.
57
+ */
58
+ export function defineMessage<S extends string>(code: string, text: LiteralText<S>): MessageDefinition<S> {
59
+ const literal = text as S;
60
+ return { code, text: literal, format: (...args) => interpolate(literal, args[0] ?? {}) };
61
+ }
62
+
63
+ const PLACEHOLDER = /\{([^}]+)\}/g;
64
+
65
+ /**
66
+ * Substitute `{name}` tokens, leaving an unfilled token in place.
67
+ *
68
+ * It must not throw. This runs over an adopter's translation as well as our own
69
+ * text, so a typo in a foreign catalogue has to degrade to a slightly wrong
70
+ * sentence rather than raise inside a toast render. Re-scanning the result to
71
+ * detect an unfilled token is what an earlier form did, and it cannot work:
72
+ * `String.replace` does not rescan replacement text, so the check could not tell
73
+ * an unfilled placeholder from user data shaped like one — an element literally
74
+ * named `{separator}` crashed at the authoring site.
75
+ */
76
+ export function interpolate(template: string, params: MessageParams): string {
77
+ // Indexed rather than `key in params`: a hand-built or version-skewed
78
+ // identity can arrive with no params at all, and `in` throws on a non-object
79
+ // where a lookup degrades.
80
+ const lookup = params as Record<string, string | number | undefined> | undefined;
81
+ return template.replace(PLACEHOLDER, (match, key: string) => {
82
+ const value = lookup?.[key];
83
+ return value === undefined ? match : String(value);
84
+ });
85
+ }
86
+
87
+ export interface MessageIdentity {
88
+ readonly code: string;
89
+ readonly params: MessageParams;
90
+ }
91
+
92
+ /**
93
+ * Envelope for a protocol `data` field. Namespaced under one key so it co-exists
94
+ * with a carrier's own `data` conventions rather than occupying `data` itself.
95
+ */
96
+ export interface HydraniumMessageData {
97
+ readonly hydranium: MessageIdentity;
98
+ }
99
+
100
+ /** An identity plus its resolved English — everything a renderer needs, on any carrier. */
101
+ export interface ResolvedMessage extends MessageIdentity {
102
+ readonly text: string;
103
+ }
104
+
105
+ export function messageData<S extends string>(message: MessageDefinition<S>, ...args: ParamsArg<S>): HydraniumMessageData {
106
+ return { hydranium: { code: message.code, params: args[0] ?? {} } };
107
+ }
108
+
109
+ /**
110
+ * Identity plus resolved English, for a hand-off carrying a value rather than a
111
+ * protocol field. The result is structured-clone safe, so it survives a process
112
+ * hop where one intervenes and costs nothing where none does.
113
+ */
114
+ export function resolve<S extends string>(message: MessageDefinition<S>, ...args: ParamsArg<S>): ResolvedMessage {
115
+ return { code: message.code, text: message.format(...args), params: args[0] ?? {} };
116
+ }
117
+
118
+ /**
119
+ * Validates every field {@link MessageIdentity} declares, `params` included.
120
+ * A guard over foreign input that checks only `code` while declaring `params`
121
+ * non-optional hands `undefined` to the renderer, which fails with the worst
122
+ * polarity available: invisible in English, crashing only once a translation is
123
+ * loaded.
124
+ */
125
+ export function hasMessageIdentity(data: unknown): data is HydraniumMessageData {
126
+ if (typeof data !== 'object' || data === null || Array.isArray(data) || !('hydranium' in data)) {
127
+ return false;
128
+ }
129
+ const identity = (data as { hydranium: unknown }).hydranium;
130
+ if (typeof identity !== 'object' || identity === null || Array.isArray(identity)) {
131
+ return false;
132
+ }
133
+ const candidate = identity as Partial<MessageIdentity>;
134
+ return typeof candidate.code === 'string' && typeof candidate.params === 'object' && candidate.params !== null;
135
+ }
136
+
137
+ /**
138
+ * A type alias rather than a subclass. Only `code`, `message` and `data` cross
139
+ * the wire, so a subclass buys nothing there: `instanceof` does not survive
140
+ * reconstruction, and the subclass costs an `Object.setPrototypeOf` in every
141
+ * constructor purely to undo what `ResponseError`'s own constructor does.
142
+ */
143
+ export type HydraniumResponseError = ResponseError<HydraniumMessageData>;
144
+
145
+ /**
146
+ * The numeric `code` and the message's catalogue code are unrelated and both are
147
+ * needed: `ResponseError.code` is an `integer`, so it cannot hold a
148
+ * `hydranium/…` key, and it is what a caller switches on after reconstruction.
149
+ */
150
+ export function messageError<S extends string>(
151
+ code: number,
152
+ message: MessageDefinition<S>,
153
+ ...params: ParamsArg<S>
154
+ ): HydraniumResponseError {
155
+ return new ResponseError(code, message.format(...params), messageData(message, ...params));
156
+ }
157
+
158
+ /**
159
+ * Render on the side that knows the reading user's locale. `translations` is
160
+ * whatever flat `code → template` map the host exposes; omitting it is how an
161
+ * adopter without i18n opts out, and yields the English.
162
+ */
163
+ export function renderFrameworkMessage(message: ResolvedMessage, translations?: Record<string, string>): string {
164
+ const template = translations?.[message.code];
165
+ return template ? interpolate(template, message.params) : message.text;
166
+ }
167
+
168
+ export function resolvedFromResponseError(error: ResponseError<unknown>): ResolvedMessage | undefined {
169
+ return hasMessageIdentity(error.data) ? { ...error.data.hydranium, text: error.message } : undefined;
170
+ }
171
+
172
+ /**
173
+ * The detail half of a `{detail}` placeholder. A technical error string is safe
174
+ * to pass as a parameter for the same reason a number is: it is not itself
175
+ * translatable text, so it needs no code of its own. A PROSE fragment is not,
176
+ * and must become one code per value instead.
177
+ */
178
+ export function describeError(error: unknown): string {
179
+ return error instanceof Error ? error.message : String(error);
180
+ }
181
+
182
+ /**
183
+ * Recognises a declaration among a barrel's exports. The `format` check is what
184
+ * discriminates: a `code` + `text` pair alone admits any object that happens to
185
+ * carry both.
186
+ */
187
+ export function isMessageDeclaration(value: unknown): value is MessageDefinition<string> {
188
+ const candidate = value as { code?: unknown; text?: unknown; format?: unknown } | null;
189
+ return (
190
+ typeof candidate === 'object' &&
191
+ candidate !== null &&
192
+ typeof candidate.code === 'string' &&
193
+ typeof candidate.text === 'string' &&
194
+ typeof candidate.format === 'function'
195
+ );
196
+ }
197
+
198
+ /**
199
+ * Every declaration a `./messages` barrel exports.
200
+ *
201
+ * A caller cannot get there with `Object.values(barrel).filter(isMessageDeclaration)`:
202
+ * a barrel's value type is a union of its declarations AND its functions, and
203
+ * `filter` will not narrow a function type down to a `MessageDefinition`, so the
204
+ * result stays the union and reading `.code` off it does not compile. Taking the
205
+ * barrel as an opaque object is what makes the one-liner work.
206
+ */
207
+ export function collectMessages(barrel: object): MessageDefinition<string>[] {
208
+ return (Object.values(barrel) as unknown[]).filter(isMessageDeclaration);
209
+ }
@@ -35,6 +35,7 @@ import { Emitter, type MessageConnection } from 'vscode-jsonrpc';
35
35
  import type { DataPort } from '../client/data-port';
36
36
  import type { DataClientProtocol } from '../data/data-server-protocol';
37
37
  import type { ProjectsChangedEvent, TransferDocumentSavedEvent, TransferDocumentUpdatedEvent } from '../data/events';
38
+ import type { ResolvedMessage } from '../messages/primitives';
38
39
  import type { Project } from '../project';
39
40
  import type { TransferDiagnostic } from '../transfer-diagnostic';
40
41
  import type { TransferElement } from '../transfer-element';
@@ -73,10 +74,11 @@ export interface FakeDataPort extends DataPort {
73
74
  /**
74
75
  * Every {@link DataPort.reportError} call, in order. Read from outside: this
75
76
  * is the only place a transport failure surfaces, so a test for the failure
76
- * path asserts on the `context` string here rather than on a rejection that
77
- * the consumer may legitimately swallow.
77
+ * path asserts here rather than on a rejection the consumer may legitimately
78
+ * swallow. Prefer asserting on `message.code`, which is stable, over
79
+ * `message.text`, which is the English default and may be reworded.
78
80
  */
79
- readonly reported: readonly { readonly error: unknown; readonly context: string }[];
81
+ readonly reported: readonly { readonly error: unknown; readonly message: ResolvedMessage }[];
80
82
  /**
81
83
  * Fire {@link DataPort.onDispose} — the host tearing the transport down, a
82
84
  * language-server restart being the case that forces the event to exist.
@@ -96,7 +98,7 @@ export interface FakeDataPort extends DataPort {
96
98
  */
97
99
  export function makeFakeDataPort(options: FakeDataPortOptions): FakeDataPort {
98
100
  const connections: MessageConnection[] = [];
99
- const reported: { error: unknown; context: string }[] = [];
101
+ const reported: { error: unknown; message: ResolvedMessage }[] = [];
100
102
  const disposeEmitter = new Emitter<void>();
101
103
  return {
102
104
  clientId: options.clientId ?? 'fake-data-port',
@@ -108,8 +110,8 @@ export function makeFakeDataPort(options: FakeDataPortOptions): FakeDataPort {
108
110
  connections.push(connection);
109
111
  return connection;
110
112
  },
111
- reportError(error: unknown, context: string): void {
112
- reported.push({ error, context });
113
+ reportError(error: unknown, message: ResolvedMessage): void {
114
+ reported.push({ error, message });
113
115
  },
114
116
  fireDispose(): void {
115
117
  disposeEmitter.fire(undefined);
@@ -7,6 +7,8 @@
7
7
  * SPDX-License-Identifier: MIT
8
8
  ********************************************************************************/
9
9
 
10
+ import { type MessageParams, type ResolvedMessage } from './messages/primitives';
11
+
10
12
  /**
11
13
  * Generic, transport-friendly diagnostic shape used by the model-server protocol.
12
14
  *
@@ -56,6 +58,21 @@ export interface TransferDiagnostic {
56
58
  * is not usable as a rule identity on its own.
57
59
  */
58
60
  code?: number | string;
61
+ /**
62
+ * Substitutions for the placeholders in the message this {@link code} names,
63
+ * present only for a diagnostic raised from a framework message declaration.
64
+ *
65
+ * Without them a translated template renders with its `{name}` tokens left
66
+ * standing, because substitution leaves an unmatched token in place rather
67
+ * than raising — so a surface that translates from {@link code} alone is
68
+ * correct for a parameterless sentence and visibly wrong for a parameterised
69
+ * one. This is the field that makes the second case work; the LSP carrier has
70
+ * always moved the params, and no carrier below it did.
71
+ *
72
+ * Prefer {@link TransferDiagnostic.resolved} over reading this: it decides
73
+ * whether an identity is present at all, which a lone `params` cannot.
74
+ */
75
+ params?: MessageParams;
59
76
  }
60
77
 
61
78
  export namespace TransferDiagnostic {
@@ -74,6 +91,29 @@ export namespace TransferDiagnostic {
74
91
  return diagnostic.type === 'parsing-error';
75
92
  }
76
93
 
94
+ /**
95
+ * The diagnostic as a renderable message, for a surface that translates.
96
+ * `undefined` when it carries no framework identity — a syntactic error, an
97
+ * adopter's own check, a linker failure — which is the case a caller must
98
+ * distinguish rather than render.
99
+ *
100
+ * Hand the result to `renderFrameworkMessage` with whatever catalogue the
101
+ * host has loaded. The `text` is the server's English, so a code the
102
+ * catalogue does not carry still yields a complete sentence.
103
+ *
104
+ * `code` alone does not establish an identity: it also holds Langium's
105
+ * internal code and an adopter's own, and either would be looked up against a
106
+ * catalogue that cannot have it. Requiring `params` is what discriminates,
107
+ * and it is why a parameterless framework message still populates the field
108
+ * with an empty object rather than omitting it.
109
+ */
110
+ export function resolved(diagnostic: TransferDiagnostic): ResolvedMessage | undefined {
111
+ if (typeof diagnostic.code !== 'string' || diagnostic.params === undefined) {
112
+ return undefined;
113
+ }
114
+ return { code: diagnostic.code, params: diagnostic.params, text: diagnostic.message };
115
+ }
116
+
77
117
  export function getPath(diagnostic: TransferDiagnostic): string {
78
118
  return diagnostic.property ? `${diagnostic.element}${ELEMENT_PROPERTY_SEPARATOR}${diagnostic.property}` : diagnostic.element;
79
119
  }