@ti-engine/core 1.9.0 → 1.10.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/CHANGELOG.md
CHANGED
|
@@ -2,6 +2,34 @@
|
|
|
2
2
|
|
|
3
3
|
This document contains the list of changes made to the framework. The format is based on the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification.
|
|
4
4
|
|
|
5
|
+
## Version 1.10.0
|
|
6
|
+
|
|
7
|
+
* feat(localization): `getLabel( label, language, fallback )` takes an optional third argument returned when the key
|
|
8
|
+
is absent from the loaded catalogue, instead of the `!!! label not found !!!` placeholder. The placeholder is an
|
|
9
|
+
internal detail and was not exported, so a caller needing this had no option but to hard-code and compare against
|
|
10
|
+
it — which `@ti-engine/web-framework` and `@ti-engine/competence` both did. The default is unchanged, so a missing
|
|
11
|
+
label stays loud for every existing call site. This matters because an application configures exactly one labels
|
|
12
|
+
path (`TI_LOCALIZATION_LABELS_PATH`) — its own — so a *framework*-owned screen resolving its own strings finds
|
|
13
|
+
nothing in a consumer and needs a literal to degrade to
|
|
14
|
+
* build(release): bump package version from `1.9.1` to `1.10.0`
|
|
15
|
+
|
|
16
|
+
## Version 1.9.1
|
|
17
|
+
|
|
18
|
+
The declarations published in 1.9.0 type-check only for a consumer who has separately configured
|
|
19
|
+
Node's types. One who has not — even with `@types/node` installed, which this package depends on —
|
|
20
|
+
gets `TS2503: Cannot find namespace 'NodeJS'` from inside `definitions.types.d.ts`.
|
|
21
|
+
|
|
22
|
+
The gate added in 1.9.0 did not catch it because it pinned `types: ["node"]` in its own compiler
|
|
23
|
+
options, putting Node's types in scope for the check and for nothing else. It reported zero errors
|
|
24
|
+
against declarations that gave a real consumer two. That pin is gone: the check now runs with
|
|
25
|
+
nothing configured, which is what a consumer's compiler does.
|
|
26
|
+
|
|
27
|
+
* fix(types): emit `/// <reference types="node" />` into declarations that name a Node global.
|
|
28
|
+
TypeScript emits no such reference on its own — not from the directive written in the JavaScript
|
|
29
|
+
source, and not from `types` set in the emit configuration; both were tried — so the declaration
|
|
30
|
+
build adds it
|
|
31
|
+
* build(release): bump package version from `1.9.0` to `1.9.1`
|
|
32
|
+
|
|
5
33
|
## Version 1.9.0
|
|
6
34
|
|
|
7
35
|
TypeScript declarations now ship with the package. The previous attempt was withdrawn in 1.8.1 because the generated
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@ti-engine/core",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.10.0",
|
|
4
4
|
"description": "Microservice framework for Node.js: a Redis-backed message exchange with end-to-end call tracing, retries and tamper-evident message envelopes.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"microservices",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
export { localizationLanguageEnum as localizationLanguage };
|
|
2
|
-
export declare var getLabel: (label: string, language?: TiLocalizationLanguage) => string;
|
|
2
|
+
export declare var getLabel: (label: string, language?: TiLocalizationLanguage, fallback?: string) => string;
|
|
3
3
|
export declare var getAllLabels: (language?: TiLocalizationLanguage) => TiLabelsTree;
|
|
4
4
|
export type TiLocalizationLanguage = string;
|
|
5
5
|
/**
|
package/utils/localization.js
CHANGED
|
@@ -250,15 +250,22 @@ tools.deepFreeze( labels );
|
|
|
250
250
|
|
|
251
251
|
/**
|
|
252
252
|
* Used to return the textual value for a label based on the current system language by default or the specified language code if provided.
|
|
253
|
+
* <br/>
|
|
254
|
+
* NOTE: A caller that has a sensible literal to show when the key is absent should pass it as `fallback` rather than
|
|
255
|
+
* comparing the result against the not-found placeholder. That placeholder is an internal detail, and a caller that
|
|
256
|
+
* hard-codes it is coupled to a string this module is free to change. This matters most for a framework-owned screen
|
|
257
|
+
* whose strings live in a catalogue the consuming application does not load — an application configures exactly one
|
|
258
|
+
* labels path, its own.
|
|
253
259
|
*
|
|
254
260
|
* @method
|
|
255
261
|
* @param {string} label This should be a dot-separated JSON path string.
|
|
256
262
|
* @param {TiLocalizationLanguage} [language] The language code to use for the lookup. If not provided, the current system language will be used.
|
|
263
|
+
* @param {string} [fallback] Returned when the label is not in the loaded catalogue. Defaults to a visible placeholder.
|
|
257
264
|
* @returns {string}
|
|
258
265
|
* @public
|
|
259
266
|
*/
|
|
260
|
-
module.exports.getLabel = ( label, language ) => {
|
|
261
|
-
return _.get( labels, label + "." + ( ( language ) ? language : config.getSetting( config.setting.LOCALIZATION_LANGUAGE ) ),
|
|
267
|
+
module.exports.getLabel = ( label, language, fallback = defaultEmptyLabel ) => {
|
|
268
|
+
return _.get( labels, label + "." + ( ( language ) ? language : config.getSetting( config.setting.LOCALIZATION_LANGUAGE ) ), fallback );
|
|
262
269
|
};
|
|
263
270
|
|
|
264
271
|
const labelsCacheByLanguage = new Map();
|