iobroker.javascript 10.0.0 → 10.1.1

package/build/types.d.ts

@@ -7,6 +7,16 @@ import type { Scheduler, SchedulerRule } from './lib/scheduler';
 import type { EventObj } from './lib/eventObj';
 import type { PatternEventCompareFunction } from './lib/patternCompareFunctions';
 import type { AstroEvent } from './lib/consts';
+import type { Secrets } from './lib/secrets';
+
+/** ECMAScript version the user scripts are compiled for */
+export type TsTarget = 'es2018' | 'es2019' | 'es2020' | 'es2021' | 'es2022' | 'es2023' | 'es2024' | 'es2025' | 'esnext';
+
+/**
+ * Value of a compiler option that may explicitly be turned on or off.
+ * An empty string means "not set", so the option follows `strict` resp. the TypeScript default.
+ */
+export type TsTriState = '' | 'true' | 'false';
 
 export interface JavaScriptAdapterConfig {
     latitude: number;
@@ -14,6 +24,8 @@ export interface JavaScriptAdapterConfig {
     enableSetObject: boolean;
     enableSendToHost: boolean;
     enableExec: boolean;
+    /** Scripts may read the central ioBroker credential store via the global `SECRETS` object */
+    enableSecrets?: boolean;
     libraries: string;
     libraryTypings: string;
     subscribe: boolean;
@@ -46,6 +58,38 @@ export interface JavaScriptAdapterConfig {
     credentialIdGeminiKey?: string;
     credentialIdDeepseekKey?: string;
     credentialIdGptBaseUrlKey?: string;
+
+    // TypeScript compiler options for the user scripts
+    tsTarget?: TsTarget;
+    tsStrict?: boolean;
+    tsNoImplicitAny?: TsTriState;
+    tsStrictNullChecks?: TsTriState;
+    tsStrictFunctionTypes?: TsTriState;
+    tsStrictBindCallApply?: TsTriState;
+    tsStrictPropertyInitialization?: TsTriState;
+    tsStrictBuiltinIteratorReturn?: TsTriState;
+    tsNoImplicitThis?: TsTriState;
+    tsAlwaysStrict?: TsTriState;
+    tsUseUnknownInCatchVariables?: TsTriState;
+    tsNoUnusedLocals?: boolean;
+    tsNoUnusedParameters?: boolean;
+    tsNoImplicitReturns?: boolean;
+    tsNoFallthroughCasesInSwitch?: boolean;
+    tsNoImplicitOverride?: boolean;
+    tsNoUncheckedIndexedAccess?: boolean;
+    tsNoPropertyAccessFromIndexSignature?: boolean;
+    tsExactOptionalPropertyTypes?: boolean;
+    tsAllowUnreachableCode?: TsTriState;
+    tsAllowUnusedLabels?: TsTriState;
+    tsNoEmitOnError?: boolean;
+    tsEsModuleInterop?: boolean;
+    tsAllowSyntheticDefaultImports?: boolean;
+    tsUseDefineForClassFields?: boolean;
+    tsDownlevelIteration?: boolean;
+    tsExperimentalDecorators?: boolean;
+    tsEmitDecoratorMetadata?: boolean;
+    tsRemoveComments?: boolean;
+    tsSkipLibCheck?: boolean;
 }
 
 export type CommonAlias = {
@@ -165,6 +209,8 @@ export type SandboxType = {
     scriptName: string;
     instance: number;
     defaultDataDir: string;
+    /** Decrypted credentials of the central ioBroker credential store, e.g. `SECRETS.CameraPassword.key` */
+    SECRETS: Secrets;
     verbose: boolean | undefined;
     exports: Record<string, any>;
     require: (md: string) => any;
@@ -758,4 +804,6 @@ export interface JavascriptContext {
     logWithLineInfo: (message: string) => void;
     schedules?: string[];
     allowSelfSignedCerts: boolean;
+    /** Decrypted credentials of the central ioBroker credential store, exposed to the scripts as `SECRETS` */
+    secrets: Secrets;
 }

package/docs/en/blockly.md

@@ -16,6 +16,8 @@
         - [Create state](#create-state)
         - [Get value of state](#get-value-of-state)
         - [Get Object ID](#get-object-id)
+        - [State exists](#state-exists)
+        - [Credential](#credential)
     - [Actions Blocks](#actions-blocks)
         - [Exec - execute](#exec---execute)
         - [request URL](#request-url)
@@ -793,6 +795,33 @@ if ((await existsStateAsync('zigbee.0.187a3efffee9e4e8.load_power'))) {
 
 **Note:** With the adapter setting *"Do not subscribe to all states on start"* enabled, `existsState` cannot be evaluated synchronously. The block emits the async form (`await existsStateAsync(...)`), so it works correctly in both modes.
 
+### Credential
+
+Reads one field of the central credential storage, which is managed in the admin under
+**Basic settings** -> **Credentials**. The secret fields are stored encrypted; the block hands the
+decrypted value to the script, so a password never has to be written into a script.
+
+The first dropdown lists the credentials that exist, the second one the fields of the selected
+credential — a credential has either a single **key** (API keys, passwords) or a **login** and a
+**password**. If the instance is not running while the editor is open, the credential list is
+unknown and the name is typed in instead.
+
+```
+Send to telegram [credential [CameraPassword] field [key]]
+```
+
+The generated JavaScript is:
+
+```javascript
+sendTo('telegram.0', SECRETS['CameraPassword']?.key);
+```
+
+The value is always current — editing a credential in the admin takes effect immediately, without
+restarting the script. A credential that was deleted yields `undefined` instead of an error.
+
+**Note:** The instance setting *"Allow scripts to read the credentials"* switches this off. `SECRETS`
+is then empty and the block returns `undefined`.
+
 ## Actions Blocks
 
 ### Exec - execute

package/docs/en/javascript.md

@@ -75,6 +75,7 @@
     - [isScriptActive](#isscriptactive)
     - [name](#scriptName)
     - [instance](#instance)
+    - [SECRETS](#secrets)
     - [messageTo](#messageto)
     - [messageToAsync](#messagetoasync)
     - [onMessage](#onmessage)
@@ -1048,6 +1049,22 @@ It is possible short type of createState:
 - `createState('myDatapoint', { name: 'My own datapoint', unit: '°C' }, () => { log('created'); });`
 - `createState('myDatapoint', 1, { name: 'My own datapoint', unit: '°C' })` - create datapoint if it does not exist with specific name and units
 
+#### An object in the second position is always the `common`
+
+These short forms are the reason why an object in the second position is **never** read as an initial
+value. `createState('myDatapoint', {}, { type: 'object' })` therefore does not do what it looks like:
+the `{}` becomes the `common`, and `{ type: 'object' }` moves on to the `native`.
+
+To give a state an initial value that is not a primitive, put it into `common.def`:
+
+```js
+createState('0_userdata.0.myObject', { name: 'My object', type: 'object', read: true, write: true, def: {} });
+```
+
+A state of type `object`, `json` or `array` keeps its value as JSON, so the state above starts out
+with the string `'{}'` - just as `setState('0_userdata.0.myObject', {})` would store it. The default
+is stringified for you; writing `def: '{}'` yourself works as well.
+
 ### createStateAsync
 ```js
 await createStateAsync(name, initialValue, forceCreation, common, native);
@@ -2064,6 +2081,61 @@ if (verbose) {
 }
 ```
 
+### SECRETS
+`SECRETS` - The credentials of the central ioBroker credential storage.
+
+The credentials are managed in the admin UI under **Basic settings** -> **Credentials**. Every credential
+has an ID (like `CameraPassword`) and holds either a single **key** (e.g. an API key or a password) or a
+**login**/**password** pair. The secret fields are stored encrypted with the system secret and are handed
+to the scripts already decrypted:
+
+```js
+// credential of the type "key"
+httpGet(`http://camera.local/snapshot?password=${SECRETS.CameraPassword.key}`, (err, result) => {
+    // ...
+});
+
+// credential of the type "login"
+log(`Mail account: ${SECRETS.MyMailAccount.login} / ${SECRETS.MyMailAccount.password}`);
+
+// credential IDs that are no valid variable names
+log(SECRETS['My camera'].key);
+```
+
+`SECRETS` is read-only and always up to date: if a credential is added, changed or deleted in the admin UI,
+the new value is used immediately - neither the adapter nor the script must be restarted.
+
+If a credential does not exist, `undefined` is returned:
+
+```js
+if (SECRETS.CameraPassword) {
+    log('The camera password is defined');
+}
+```
+
+#### Which fields does a credential have?
+
+Every credential has either a single `key` or a `login`/`password` pair. Three ways to find out which:
+
+- In the instance settings of the JavaScript adapter, the section **Available credentials** lists every
+  credential with its fields and the ready-to-copy expression.
+- In the editor, the auto-completion after `SECRETS.` offers the credentials that exist, and after the
+  next dot exactly the fields that credential has.
+- In a script:
+
+```js
+log(JSON.stringify(Object.keys(SECRETS.CameraPassword))); // ["key"]
+log(JSON.stringify(Object.keys(SECRETS.MyMailAccount))); // ["login","password"]
+```
+
+Blockly has a **credential** block for the same purpose - see the
+[Blockly documentation](blockly.md#credential).
+
+The access can be switched off with the instance option **Allow scripts to read the credentials**.
+`SECRETS` is then empty and a warning is written to the log.
+
+**Note:** this requires js-controller 7.2 or newer.
+
 ## Option - "Do not subscribe all states on start"
 There are two modes of subscribing to states:
 

package/docs/en/upgrade-guide.md

@@ -18,6 +18,9 @@ When enabling the script files system mirroring, please make sure to create a **
 Please also make sure that no other script or process changes files in the provided directory to prevent access issues.
 Any location needs to be writable by the "iobroker" user!
 
+The sync goes both ways, and that includes deletions: **when a folder disappears from the mirror directory, the scripts in it are deleted from the ioBroker database.**
+So anything else that writes there - a backup job, a cleanup task, a deployment - can remove your scripts. Only if the mirror directory as a whole becomes unreachable, e.g. because a share is not mounted, the scripts are kept and the directory is written again on the next start.
+
 ## request to httpGet
 
 **Since v8.0.0 of the JavaScript adapter** the `request` package is deprecated and the usage in your scripts will raise a warning.

package/io-package.json

@@ -1,7 +1,7 @@
 {
   "common": {
     "name": "javascript",
-    "version": "10.0.0",
+    "version": "10.1.1",
     "blockedVersions": [
       "8.0.0",
       "8.0.1"
@@ -40,6 +40,32 @@
       "Matthias Kleine <info@haus-automatisierung.com>"
     ],
     "news": {
+      "10.1.1": {
+        "en": "The credentials of the central storage (Basic settings -> Credentials) are available in the scripts as `SECRETS`, e.g. `SECRETS.CameraPassword.key`. The values are decrypted, read-only and are updated live when a credential is edited in the admin UI\nThe editor knows the credentials that exist: after `SECRETS.` it offers their names, and after the next dot exactly the fields the selected credential has\nAdded the Blockly block \"credential\", which reads one field of the central credential storage\nThe instance settings list the available credentials with their fields and the expression a script uses for them",
+        "de": "Die Zugangsdaten für den zentralen Speicher (Grundeinstellungen → Zugangsdaten) sind in den Skripten als `SECRETS` verfügbar, z. B. `SECRETS.CameraPassword.key`. Die Werte sind entschlüsselt, schreibgeschützt und werden live aktualisiert, sobald ein Zugangsdatum in der Admin-Oberfläche bearbeitet wird.\nDer Editor kennt die vorhandenen Zugangsdaten: Nach `SECRETS.` werden deren Namen angezeigt, und nach dem nächsten Punkt genau die Felder, die die ausgewählten Zugangsdaten enthalten.\nDer Blockly-Block „credential“ wurde hinzugefügt, der ein Feld des zentralen Anmeldeinformationsspeichers ausliest.\nDie Instanzeinstellungen listen die verfügbaren Anmeldeinformationen mit ihren Feldern und dem Ausdruck auf, den ein Skript dafür verwendet.",
+        "ru": "Учетные данные центрального хранилища (Основные настройки -> Учетные данные) доступны в скриптах как `SECRETS`, например, `SECRETS.CameraPassword.key`. Значения расшифрованы, доступны только для чтения и обновляются в режиме реального времени при редактировании учетных данных в административном интерфейсе.\nРедактор знает существующие учетные данные: после `SECRETS.` он отображает их названия, а после следующей точки — точное описание полей, которыми обладают выбранные учетные данные.\nДобавлен блок Blockly \"учетные данные\", который считывает одно поле из центрального хранилища учетных данных.\nВ параметрах экземпляра отображаются доступные учетные данные с указанием их полей и выражения, используемого скриптом для их обработки.",
+        "pt": "As credenciais do armazenamento central (Configurações básicas -> Credenciais) estão disponíveis nos scripts como `SECRETS`, por exemplo, `SECRETS.CameraPassword.key`. Os valores são descriptografados, somente leitura e atualizados em tempo real quando uma credencial é editada na interface administrativa.\nO editor conhece as credenciais existentes: após `SECRETS.`, ele exibe os nomes delas e, após o ponto seguinte, exatamente os campos que a credencial selecionada possui.\nAdicionado o bloco Blockly \"credential\", que lê um campo do armazenamento central de credenciais.\nAs configurações da instância listam as credenciais disponíveis com seus respectivos campos e a expressão que um script utiliza para elas.",
+        "nl": "De inloggegevens voor de centrale opslag (Basisinstellingen -> Inloggegevens) zijn beschikbaar in de scripts als `SECRETS`, bijvoorbeeld `SECRETS.CameraPassword.key`. De waarden zijn onversleuteld, alleen-lezen en worden live bijgewerkt wanneer een inloggegeven wordt bewerkt in de beheerdersinterface.\nDe editor kent de bestaande inloggegevens: na `SECRETS.` worden de namen weergegeven, en na de volgende punt worden precies de velden vermeld die de geselecteerde inloggegevens bevatten.\nHet Blockly-blok \"credential\" is toegevoegd, dat één veld uit de centrale opslag voor inloggegevens leest.\nDe instantie-instellingen tonen de beschikbare referenties met hun velden en de expressie die een script hiervoor gebruikt.",
+        "fr": "Les identifiants du stockage central (Paramètres de base -> Identifiants) sont disponibles dans les scripts sous le nom `SECRETS`, par exemple `SECRETS.CameraPassword.key`. Ces valeurs sont déchiffrées, en lecture seule et mises à jour en temps réel lorsqu'un identifiant est modifié dans l'interface d'administration.\nL'éditeur connaît les identifiants existants : après `SECRETS.`, il affiche leurs noms, et après le point suivant, les champs exacts de l'identifiant sélectionné.\nAjout du bloc Blockly « credential », qui lit un champ du stockage central des identifiants.\nLes paramètres de l'instance listent les informations d'identification disponibles, leurs champs et l'expression utilisée par un script pour celles-ci.",
+        "it": "Le credenziali dell'archivio centrale (Impostazioni di base -> Credenziali) sono disponibili negli script come `SECRETS`, ad esempio `SECRETS.CameraPassword.key`. I valori sono decrittografati, di sola lettura e vengono aggiornati in tempo reale quando una credenziale viene modificata nell'interfaccia di amministrazione.\nL'editor conosce le credenziali esistenti: dopo `SECRETS.` ne mostra i nomi e dopo il punto successivo esattamente i campi che la credenziale selezionata ha\nAggiunto il blocco Blockly \"credential\", che legge un campo dell'archivio centrale delle credenziali.\nLe impostazioni dell'istanza elencano le credenziali disponibili con i relativi campi e l'espressione che uno script utilizza per esse.",
+        "es": "Las credenciales del almacenamiento central (Configuración básica -> Credenciales) están disponibles en los scripts como `SECRETS`, por ejemplo, `SECRETS.CameraPassword.key`. Los valores están descifrados, son de solo lectura y se actualizan en tiempo real cuando se edita una credencial en la interfaz de administración.\nEl editor conoce las credenciales existentes: después de `SECRETS.` ofrece sus nombres, y después del siguiente punto exactamente los campos que tiene la credencial seleccionada.\nSe agregó el bloque Blockly \"credential\", que lee un campo del almacenamiento central de credenciales.\nLa configuración de la instancia enumera las credenciales disponibles con sus campos y la expresión que un script utiliza para ellas.",
+        "pl": "Dane uwierzytelniające centralnego magazynu (Ustawienia podstawowe -> Dane uwierzytelniające) są dostępne w skryptach jako `SECRETS`, np. `SECRETS.CameraPassword.key`. Wartości są odszyfrowywane, tylko do odczytu i aktualizowane na bieżąco podczas edycji danych uwierzytelniających w interfejsie administratora.\nEdytor zna istniejące dane uwierzytelniające: po poleceniu „SECRETS.” podaje ich nazwy, a po kolejnej kropce dokładnie pola, w których znajdują się wybrane dane uwierzytelniające.\nDodano blok Blockly „poświadczenia”, który odczytuje jedno pole centralnego magazynu poświadczeń\nUstawienia instancji zawierają listę dostępnych poświadczeń wraz z ich polami i wyrażeniem używanym przez skrypt w ich przypadku",
+        "uk": "Облікові дані центрального сховища (Основні налаштування -> Облікові дані) доступні у скриптах як `SECRETS`, наприклад, `SECRETS.CameraPassword.key`. Значення розшифровуються, доступні лише для читання та оновлюються в режимі реального часу під час редагування облікових даних в інтерфейсі адміністратора.\nРедактор знає наявні облікові дані: після `SECRETS.` він пропонує їхні імена, а після наступної крапки точно поля, які мають вибрані облікові дані.\nДодано блок Blockly \"credential\", який зчитує одне поле центрального сховища облікових даних.\nУ налаштуваннях екземпляра перелічено доступні облікові дані з їхніми полями та виразом, який використовує для них скрипт.",
+        "zh-cn": "中央存储的凭据（基本设置 -> 凭据）在脚本中以 `SECRETS` 的形式提供，例如 `SECRETS.CameraPassword.key`。这些值已解密，为只读，并在管理员界面编辑凭据时实时更新。\n编辑器知道存在的凭据：在“SECRETS.”之后，它会显示凭据的名称；在下一个点之后，它会显示所选凭据包含的具体字段。\n新增了 Blockly 代码块“credential”，该代码块读取中央凭证存储中的一个字段。\n实例设置列出了可用的凭据及其字段，以及脚本用于这些凭据的表达式。"
+      },
+      "10.1.0": {
+        "en": "Turned `strict` off again for the scripts, as TypeScript 6 enables it by default\nAdded the tab \"TypeScript\" to the settings, where the compiler options for the scripts can be configured\nAdded snapshot tests for the Blockly code generation (`npm run test:blockly`)\nRemoved two leftover `.only` markers that had disabled almost the whole test suite\nPinned the line endings of transformed TypeScript sources to LF, so a compiler update cannot rewrite every script\nMoved the micro benchmarks into `npm run test:performance`, as they measure relative speed against timeouts and cannot block a build\nUpdated Blockly from 11.1.1 to 13.2.1. The generated code is unchanged\n`updateBlockly.js` now copies from the installed npm package instead of cloning the git master branch, so the shipped Blockly version is reproducible\nBlockly is now bundled from the npm package instead of being loaded as vendored script tags. Custom blocks of other adapters keep working unchanged\nRemoved 828 kB of vendored Blockly code from the repository\nConverted all block definitions from JavaScript to TypeScript. The generated code is unchanged\nFixed the object blocks under Blockly 13: the attribute rows were no longer right-aligned, and editing the attributes of an \"object\" block threw\nDropped the dead field editor code of the CRON and script fields, which had been written against Blockly 1.x\nFixed the multi-and/multi-or blocks under Blockly 13, which threw when their conditions were edited\nRemoved a phantom block type \"Convert\" that a stray assignment in the conversion blocks had registered\nAdded `BLOCKLY_TS.md` for adapter developers: what Blockly 13 changed for custom blocks and how to write them in TypeScript\nMoved the Blockly translations into `words.json` and typed the lookup helpers\nRedesign of Rules\nAdded a wizard to the rule editor that builds a rule step by step - trigger, condition and action are configured in place, and the last step shows the finished rule\nThe wizard opens by itself for a newly created rule - once, and not for a duplicated one. Afterwards it stays available in the block palette\nFixed the type declarations of 3rd party libraries: they were placed under the name the library has on disk while their `package.json` went to the name the scripts import, so TypeScript never connected the two and everything imported from such a library was `any` (#2341)\nStopped wrapping a library's declarations in `declare module`, which cut a barrel file off from what it re-exports. Declarations that are not a module themselves are still wrapped\nFixed following the imports inside a declaration file: only the first import of a file was followed, and only if it was on the first line. For rxjs 6 that loaded 6 of its ~800 declaration files\nSide effect imports (`import \"./x\";`) inside a declaration file are now followed as well. `@iobroker/types` consists of nothing else, so the `ioBroker.*` types were missing in scripts and in the editor\nA definition file that cannot be read no longer discards all type declarations of its package\nAdded regression tests for the type declarations of 3rd party libraries, which compile against them and insist that wrong code is rejected\n`createState` now stringifies `common.def` of an object, json or array state, as js-controller expects it and as `setState` already does with the value. Creating such a state with an initial value no longer warns \"Default value has to be stringified\" (#2307)\nDocumented that an object in the second position of `createState` is always the `common`, and how to give a state a non-primitive initial value\nRestored the check of the mirror path in the instance configuration. It was lost when the admin configuration moved to `jsonConfig.json`, so a forbidden path was accepted without a word and only refused later in the log (#2296)\nThe mirror path field now explains what the directory has to be, and suggests one\nScripts are no longer deleted from the database when the mirror directory as a whole becomes unreachable, e.g. because a share is not mounted\nLibraries that name their declarations through an `exports` map are typed now. Their legacy `types` field is often a stub pointing at a file that does not exist - rxjs 7 is one - which left everything imported from them as `any` (#928)\nThe declarations of a library are laid out around its entry point, so `moduleResolution: node10` finds it even when they live in a subdirectory\nThe manifest handed to TypeScript describes that layout instead of the one on disk. An `exports` map pointing at paths that do not exist there made TypeScript refuse the library altogether\nThe package.json of a library is read from disk instead of through Node, which refuses it when the library does not export it\nFixed the mirror tests on macOS. They asserted on the first event a watcher reported, while `fs.watch` there works at directory granularity and sends an event for the watched directory before the one for the file. They now wait for the change they are about, and say what arrived instead if it never comes\nMade the mirror tests independent of how long a watch takes to arm. The change under test is repeated while waiting, so it cannot be made before the watcher is listening - the same commit produced a green and a red macOS job over that",
+        "de": "Ich habe `strict` für die Skripte wieder deaktiviert, da TypeScript 6 es standardmäßig aktiviert.\nDen Einstellungen wurde der Tab „TypeScript“ hinzugefügt, über den die Compileroptionen für die Skripte konfiguriert werden können.\nSnapshot-Tests für die Blockly-Codegenerierung hinzugefügt (`npm run test:blockly`)\nZwei überflüssige `.only`-Markierungen wurden entfernt, die fast die gesamte Testsuite deaktiviert hatten.\nDie Zeilenumbrüche der transformierten TypeScript-Quelltexte wurden auf LF fixiert, sodass ein Compiler-Update nicht jedes Skript überschreiben kann.\nDie Mikro-Benchmarks wurden in `npm run test:performance` verschoben, da sie die relative Geschwindigkeit im Vergleich zu Timeouts messen und einen Build nicht blockieren können.\nBlockly wurde von Version 11.1.1 auf 13.2.1 aktualisiert. Der generierte Code ist unverändert.\n`updateBlockly.js` kopiert nun vom installierten npm-Paket, anstatt den Git-Master-Branch zu klonen, sodass die ausgelieferte Blockly-Version reproduzierbar ist.\nBlockly ist jetzt im npm-Paket enthalten und wird nicht mehr als Skript-Tag geladen. Benutzerdefinierte Blöcke anderer Adapter funktionieren weiterhin unverändert.\n828 kB an mitgeliefertem Blockly-Code wurden aus dem Repository entfernt.\nAlle Blockdefinitionen wurden von JavaScript nach TypeScript konvertiert. Der generierte Code ist unverändert.\nDie Objektblöcke unter Blockly 13 wurden korrigiert: Die Attributzeilen waren nicht mehr rechtsbündig, und das Bearbeiten der Attribute eines „Objekt“-Blocks führte zu einem Fehler.\nDer veraltete Code des Feldeditors für die CRON- und Skriptfelder, der für Blockly 1.x geschrieben worden war, wurde entfernt.\nDie Fehler in den Mehrfach-UND-/Mehrfach-ODER-Blöcken unter Blockly 13, die beim Bearbeiten ihrer Bedingungen zu Problemen führten, wurden behoben.\nEin Phantomblock vom Typ „Konvertieren“, der durch eine fehlerhafte Zuweisung in den Konvertierungsblöcken registriert worden war, wurde entfernt.\nDie Datei `BLOCKLY_TS.md` wurde für Adapterentwickler hinzugefügt: Sie beschreibt die Änderungen in Blockly 13 für benutzerdefinierte Blöcke und wie diese in TypeScript geschrieben werden.\nDie Blockly-Übersetzungen wurden in `words.json` verschoben und die Suchhilfen eingegeben.\nNeugestaltung der Regeln\nDem Regeleditor wurde ein Assistent hinzugefügt, der eine Regel Schritt für Schritt erstellt – Auslöser, Bedingung und Aktion werden direkt konfiguriert, und der letzte Schritt zeigt die fertige Regel an.\nDer Assistent öffnet sich automatisch für eine neu erstellte Regel – einmalig, nicht jedoch für eine duplizierte. Anschließend bleibt er in der Blockpalette verfügbar.\nDie Typdeklarationen von Drittanbieterbibliotheken wurden korrigiert: Sie wurden unter dem Namen abgelegt, den die Bibliothek auf der Festplatte hat, während ihre `package.json` den Namen trug, den die Skripte importieren. Daher konnte TypeScript die beiden nie miteinander verknüpfen, und alles, was aus einer solchen Bibliothek importiert wurde, war `any` (#2341).\nDie Deklarationen einer Bibliothek werden nicht mehr in `declare module` eingeschlossen, wodurch eine Barrel-Datei von ihren Exporten abgeschnitten wurde. Deklarationen, die selbst kein Modul sind, werden weiterhin eingeschlossen.\nDas Problem mit den Importen innerhalb einer Deklarationsdatei wurde behoben: Es wurde nur der erste Import einer Datei berücksichtigt, und zwar nur dann, wenn er in der ersten Zeile stand. Dies betraf rxjs 6, das 6 seiner ca. 800 Deklarationsdateien lud.\nImporte mit Seiteneffekten (`import \"./x\";`) innerhalb einer Deklarationsdatei werden nun ebenfalls berücksichtigt. `@iobroker/types` enthält nichts anderes, daher fehlten die `ioBroker.*`-Typen in Skripten und im Editor.\nEine nicht lesbare Definitionsdatei verwirft nicht mehr alle Typdeklarationen ihres Pakets.\nEs wurden Regressionstests für die Typdeklarationen von Drittanbieterbibliotheken hinzugefügt, die gegen diese kompilieren und darauf bestehen, dass fehlerhafter Code zurückgewiesen wird.\n`createState` wandelt nun den `common.def`-Wert eines Objekts, JSON- oder Array-Zustands in einen String um, wie es js-controller erwartet und wie `setState` es bereits mit dem Wert tut. Das Erstellen eines solchen Zustands mit einem Anfangswert führt nicht mehr zu der Warnung „Standardwert muss in einen String umgewandelt werden“ (#2307).\nEs wurde dokumentiert, dass ein Objekt an der zweiten Position von `createState` immer das `common` ist, und wie man einem Zustand einen nicht-primitiven Anfangswert zuweist.\nDie Überprüfung des Spiegelpfads in der Instanzkonfiguration wurde wiederhergestellt. Sie war verloren gegangen, als die Administratorkonfiguration in die Datei `jsonConfig.json` verschoben wurde, sodass ein verbotener Pfad zunächst ohne Fehlermeldung akzeptiert und erst später im Protokoll als ungültig gemeldet wurde (#2296).\nDas Feld „Spiegelpfad“ erklärt nun, welches Verzeichnis verwendet werden muss, und schlägt eines vor.\nSkripte werden nicht mehr aus der Datenbank gelöscht, wenn das gesamte Spiegelverzeichnis nicht mehr erreichbar ist, z. B. weil eine Freigabe nicht eingebunden ist.\nBibliotheken, die ihre Deklarationen über eine `exports`-Map benennen, sind jetzt typisiert. Ihr veraltetes `types`-Feld ist oft ein Platzhalter, der auf eine nicht existierende Datei verweist – rxjs 7 ist ein Beispiel dafür –, wodurch alles, was von ihnen importiert wird, als `any` (#928) zurückbleibt.\nDie Deklarationen einer Bibliothek sind um ihren Einstiegspunkt herum angeordnet, sodass `moduleResolution: node10` sie auch dann findet, wenn sie sich in einem Unterverzeichnis befinden.\nDas an TypeScript übergebene Manifest beschreibt dieses Layout anstelle des auf der Festplatte befindlichen. Eine `exports`-Map, die auf nicht existierende Pfade verweist, führte dazu, dass TypeScript die Bibliothek vollständig ablehnte.\nDie package.json einer Bibliothek wird von der Festplatte gelesen, anstatt über Node.js, das sie ablehnt, wenn die Bibliothek sie nicht exportiert.\nDie Spiegeltests unter macOS wurden korrigiert. Sie prüften das erste vom Watcher gemeldete Ereignis, während `fs.watch` dort auf Verzeichnisebene arbeitet und ein Ereignis für das überwachte Verzeichnis vor dem für die Datei sendet. Sie warten nun auf die betreffende Änderung und geben das Ergebnis aus, falls diese nicht eintritt.\nDie Spiegeltests wurden unabhängig von der Aktivierungszeit der Watch durchgeführt. Die zu testende Änderung wird während des Wartens wiederholt und kann daher erst erfolgen, nachdem die Watch aktiv ist – derselbe Commit erzeugte sowohl einen grünen als auch einen roten macOS-Job.",
+        "ru": "Снова отключил параметр `strict` для скриптов, поскольку в TypeScript 6 он включен по умолчанию.\nВ настройки добавлена вкладка \"TypeScript\", где можно настроить параметры компилятора для скриптов.\nДобавлены тесты для генерации кода Blockly (`npm run test:blockly`).\nУдалены два оставшихся маркера `.only`, которые отключили почти весь набор тестов.\nВ преобразованных исходных файлах TypeScript символы конца строки зафиксированы на LF, поэтому обновление компилятора не сможет перезаписать каждый скрипт.\nМикротесты производительности перенесены в `npm run test:performance`, поскольку они измеряют относительную скорость относительно таймаутов и не могут блокировать сборку.\nОбновлена версия Blockly с 11.1.1 до 13.2.1. Сгенерированный код остался без изменений.\nТеперь `updateBlockly.js` копирует изменения из установленного npm-пакета вместо клонирования ветки git master, поэтому версия Blockly, поставляемая с продуктом, воспроизводится корректно.\nТеперь Blockly интегрируется из npm-пакета, а не загружается как встроенные теги скриптов. Пользовательские блоки других адаптеров работают без изменений.\nИз репозитория удалено 828 КБ кода Blockly, используемого в качестве стороннего ресурса.\nВсе определения блоков кода преобразованы из JavaScript в TypeScript. Сгенерированный код остался без изменений.\nИсправлены блоки объектов в Blockly 13: строки атрибутов больше не выравнивались по правому краю, а редактирование атрибутов блока «объект» вызывало ошибки.\nУдалён неработающий код редактора полей CRON и скриптов, написанный для Blockly 1.x.\nИсправлена ошибка в блоках \"множественное И/множественное ИЛИ\" в Blockly 13, которая возникала при редактировании их условий.\nУдалён фантомный блок типа «Преобразование», зарегистрированный из-за случайного присваивания в блоках преобразования.\nДобавлен файл `BLOCKLY_TS.md` для разработчиков адаптеров: что изменилось в Blockly 13 для пользовательских блоков и как их писать на TypeScript.\nПереместил переводы Blockly в файл `words.json` и добавил вспомогательные функции поиска.\nПересмотр правил\nВ редактор правил добавлен мастер, который создает правило шаг за шагом — триггер, условие и действие настраиваются автоматически, а на последнем шаге отображается готовое правило.\nМастер открывается автоматически для каждого нового правила — один раз, а не для дублирующихся. После этого он остается доступным на палитре блоков.\nИсправлены объявления типов сторонних библиотек: они размещались под именем, которое библиотека имеет на диске, в то время как их файл `package.json` указывал на имя, которое импортируют скрипты, поэтому TypeScript никогда не связывал эти два имени, и все, что импортировалось из такой библиотеки, имело значение `any` (#2341)\nПрекратили оборачивать объявления библиотек в `declare module`, что приводило к отделению файла-контейнера от того, что он реэкспортирует. Объявления, которые сами по себе не являются модулями, по-прежнему оборачиваются.\nИсправлена ошибка, связанная с отслеживанием импортов внутри файла объявлений: отслеживался только первый импорт в файле и только если он находился на первой строке. Для rxjs 6, который загружал 6 из своих ~800 файлов объявлений.\nИмпорт побочных эффектов (`import \"./x\";`) внутри файла объявления теперь также обрабатывается. `@iobroker/types` не содержит ничего, кроме типов `ioBroker.*`, поэтому типы `ioBroker.*` отсутствовали в скриптах и в редакторе.\nФайл определения, который невозможно прочитать, больше не отбрасывает все объявления типов своего пакета.\nДобавлены регрессионные тесты для объявлений типов сторонних библиотек, которые компилируются с ними и настаивают на отклонении некорректного кода.\nТеперь `createState` преобразует `common.def` объекта, JSON или массива состояния в строку, как и ожидает js-controller и как это уже делает `setState` со значением. Создание такого состояния с начальным значением больше не выдает предупреждение «Значение по умолчанию должно быть преобразовано в строку» (#2307).\nДокументировано, что объект на второй позиции в `createState` всегда является `common`, а также как присвоить состоянию не примитивное начальное значение.\nВосстановлена проверка пути к зеркалу в конфигурации экземпляра. Она была потеряна, когда административная конфигурация переместилась в `jsonConfig.json`, поэтому запрещенный путь принимался без объяснения причин и отклонялся только позже в логе (#2296).\nВ поле «Путь к зеркалу» теперь поясняется, какой должна быть директория, и предлагается один из вариантов.\nСкрипты больше не удаляются из базы данных, когда зеркальный каталог в целом становится недоступным, например, из-за того, что общий ресурс не смонтирован.\nБиблиотеки, которые называют свои объявления через карту `exports`, теперь типизированы. Их устаревшее поле `types` часто является заглушкой, указывающей на несуществующий файл — rxjs 7 тому пример — из-за чего все импортируемые из них файлы имели значение `any` (#928).\nОбъявления библиотеки располагаются вокруг точки входа, поэтому `moduleResolution: node10` находит её, даже если она находится в подкаталоге.\nВ манифесте, переданном TypeScript, описывается именно такая структура, а не та, что находится на диске. Карта `exports`, указывающая на пути, которых там не существует, привела к тому, что TypeScript полностью отклонил библиотеку.\nФайл package.json библиотеки считывается с диска, а не через Node.js, который отклоняет его, если библиотека не экспортирует этот файл.\nИсправлены тесты зеркалирования на macOS. Они проверяли наличие первого события, о котором сообщал наблюдатель, в то время как `fs.watch` там работает на уровне каталогов и отправляет событие для отслеживаемого каталога раньше, чем для файла. Теперь они ждут изменения, о котором идет речь, и сообщают о том, что произошло, если оно так и не происходит.\nСделаны зеркальные тесты независимыми от времени, необходимого для активации системы с помощью наблюдателя. Тестируемое изменение повторяется во время ожидания, поэтому его нельзя внести до того, как наблюдатель начнет отслеживать изменения — один и тот же коммит привел к положительному и отрицательному результату задания macOS в этом случае.",
+        "pt": "Desativei novamente o modo `strict` para os scripts, já que o TypeScript 6 o habilita por padrão.\nAdicionamos a aba \"TypeScript\" às configurações, onde as opções do compilador para os scripts podem ser configuradas.\nAdicionados testes de snapshot para a geração de código Blockly (`npm run test:blockly`)\nForam removidos dois marcadores `.only` remanescentes que haviam desativado quase todo o conjunto de testes.\nFixei as quebras de linha das fontes TypeScript transformadas em LF, para que uma atualização do compilador não possa reescrever todos os scripts.\nOs microbenchmarks foram movidos para `npm run test:performance`, pois medem a velocidade relativa em relação aos tempos limite e não podem bloquear uma compilação.\nAtualizei o Blockly da versão 11.1.1 para a 13.2.1. O código gerado permanece inalterado.\nO arquivo `updateBlockly.js` agora copia os arquivos do pacote npm instalado em vez de clonar o branch master do git, portanto, a versão do Blockly distribuída é reproduzível.\nO Blockly agora é distribuído pelo pacote npm em vez de ser carregado como tags de script externas. Blocos personalizados de outros adaptadores continuam funcionando sem alterações.\nRemovemos 828 kB de código Blockly incluído no repositório.\nTodas as definições de bloco foram convertidas de JavaScript para TypeScript. O código gerado permanece inalterado.\nCorrigido o problema com os blocos de objeto no Blockly 13: as linhas de atributos não estavam mais alinhadas à direita e editar os atributos de um bloco \"objeto\" causava erros.\nRemovi o código obsoleto do editor de campos dos campos CRON e script, que havia sido escrito para o Blockly 1.x.\nCorrigido o problema com os blocos multi-and/multi-or no Blockly 13, que causavam erros quando suas condições eram editadas.\nRemovemos um bloco fantasma do tipo \"Converter\" que havia sido registrado devido a uma atribuição acidental nos blocos de conversão.\nAdicionado o arquivo `BLOCKLY_TS.md` para desenvolvedores de adaptadores: o que o Blockly 13 mudou para blocos personalizados e como escrevê-los em TypeScript.\nMovi as traduções do Blockly para `words.json` e digitei os auxiliares de pesquisa.\nReformulação das Regras\nAdicionamos um assistente ao editor de regras que cria uma regra passo a passo — o gatilho, a condição e a ação são configurados no local, e a última etapa exibe a regra finalizada.\nO assistente abre automaticamente para uma regra recém-criada — apenas uma vez, e não para uma regra duplicada. Depois disso, ele permanece disponível na paleta de blocos.\nCorrigidas as declarações de tipo de bibliotecas de terceiros: elas eram colocadas sob o nome que a biblioteca tem no disco, enquanto seu `package.json` ia para o nome que os scripts importam, então o TypeScript nunca conectava os dois e tudo importado de tal biblioteca era `any` (#2341)\nO encapsulamento das declarações de uma biblioteca em `declare module` foi interrompido, pois isso impedia a reexportação de um arquivo de barril. Declarações que não constituem um módulo em si ainda são encapsuladas.\nCorrigido o problema de seguir as importações dentro de um arquivo de declaração: apenas a primeira importação de um arquivo era seguida, e somente se estivesse na primeira linha. Isso era necessário para o rxjs 6, que carregava 6 dos seus aproximadamente 800 arquivos de declaração.\nAs importações com efeitos colaterais (`import \"./x\";`) dentro de um arquivo de declaração agora também são consideradas. `@iobroker/types` não contém mais nada, portanto os tipos `ioBroker.*` estavam ausentes nos scripts e no editor.\nUm arquivo de definição que não pode ser lido deixa de descartar todas as declarações de tipo do seu pacote.\nAdicionadas análises de regressão para as declarações de tipo de bibliotecas de terceiros, que compilam com base nessas bibliotecas e exigem que o código incorreto seja rejeitado.\n`createState` agora converte `common.def` de um objeto, JSON ou array de estado em string, como o js-controller espera e como `setState` já faz com o valor. Criar um estado desse tipo com um valor inicial não exibe mais o aviso \"O valor padrão precisa ser convertido em string\" (#2307)\nDocumentado que um objeto na segunda posição de `createState` é sempre o `common`, e como atribuir um valor inicial não primitivo a um estado.\nRestaurada a verificação do caminho do espelho na configuração da instância. Ela foi perdida quando a configuração administrativa foi movida para `jsonConfig.json`, então um caminho proibido era aceito sem aviso prévio e só era recusado posteriormente no log (#2296).\nO campo do caminho do espelho agora explica qual deve ser o diretório e sugere um.\nOs scripts não são mais excluídos do banco de dados quando o diretório espelho como um todo se torna inacessível, por exemplo, porque um compartilhamento não está montado.\nBibliotecas que nomeiam suas declarações por meio de um mapa `exports` agora são tipadas. Seu campo `types` legado é frequentemente um stub apontando para um arquivo que não existe - rxjs 7 é um exemplo - o que deixava tudo importado delas como `any` (#928)\nAs declarações de uma biblioteca são organizadas em torno de seu ponto de entrada, portanto, `moduleResolution: node10` a encontra mesmo quando ela está em um subdiretório.\nO manifesto entregue ao TypeScript descreve esse layout em vez do layout presente no disco. Um mapa `exports` apontando para caminhos que não existem fez com que o TypeScript rejeitasse a biblioteca por completo.\nO arquivo package.json de uma biblioteca é lido do disco em vez de ser lido pelo Node, que o rejeita quando a biblioteca não o exporta.\nCorrigidos os testes de espelhamento no macOS. Eles verificavam o primeiro evento relatado por um observador, enquanto o `fs.watch` funciona com granularidade de diretório e envia um evento para o diretório observado antes do evento para o arquivo. Agora, eles aguardam a alteração que estão monitorando e, caso ela nunca ocorra, informam o que aconteceu.\nTornei os testes de espelhamento independentes do tempo que um observador leva para armar. A alteração em teste é repetida durante a espera, portanto, não pode ser feita antes que o observador esteja escutando — o mesmo commit gerou um job do macOS com resultado positivo e um com resultado negativo.",
+        "nl": "Ik heb `strict` weer uitgeschakeld voor de scripts, aangezien TypeScript 6 dit standaard inschakelt.\nHet tabblad \"TypeScript\" is toegevoegd aan de instellingen, waar de compileropties voor de scripts kunnen worden geconfigureerd.\nEr zijn snapshot-tests toegevoegd voor de Blockly-codegeneratie (`npm run test:blockly`).\nTwee overgebleven `.only`-markeringen verwijderd die bijna de hele testsuite hadden uitgeschakeld.\nDe regeleinden van de getransformeerde TypeScript-broncode zijn vastgezet op LF, zodat een compilerupdate niet elk script kan herschrijven.\nDe microbenchmarks zijn verplaatst naar `npm run test:performance`, omdat ze de relatieve snelheid meten ten opzichte van time-outs en een build niet kunnen blokkeren.\nBlockly is bijgewerkt van 11.1.1 naar 13.2.1. De gegenereerde code is ongewijzigd.\n`updateBlockly.js` kopieert nu vanuit het geïnstalleerde npm-pakket in plaats van de master-branch van Git te klonen, waardoor de geleverde Blockly-versie reproduceerbaar is.\nBlockly wordt nu meegeleverd met het npm-pakket in plaats van te worden geladen als meegeleverde scripttags. Aangepaste blokken van andere adapters blijven ongewijzigd werken.\n828 kB aan Blockly-code die door derden werd gebruikt, is uit de repository verwijderd.\nAlle blokdefinities zijn geconverteerd van JavaScript naar TypeScript. De gegenereerde code is ongewijzigd.\nDe objectblokken onder Blockly 13 zijn gecorrigeerd: de rijen met attributen waren niet langer rechts uitgelijnd en het bewerken van de attributen van een \"object\"-blok veroorzaakte fouten.\nDe verouderde code voor de CRON- en scriptvelden, die was geschreven voor Blockly 1.x, is verwijderd.\nDe multi-and/multi-or-blokken in Blockly 13 zijn gecorrigeerd; deze gaven een foutmelding wanneer hun voorwaarden werden gewijzigd.\nEen spookachtig bloktype \"Convert\" is verwijderd, dat was geregistreerd door een onbedoelde toewijzing in de conversieblokken.\n`BLOCKLY_TS.md` toegevoegd voor adapterontwikkelaars: wat Blockly 13 heeft veranderd voor aangepaste blokken en hoe je deze in TypeScript kunt schrijven.\nDe Blockly-vertalingen zijn verplaatst naar `words.json` en de opzoekhulpen zijn ingevoerd.\nHerziening van de regels\nEr is een wizard toegevoegd aan de regeleditor die stap voor stap een regel opbouwt: trigger, voorwaarde en actie worden geconfigureerd en in de laatste stap wordt de voltooide regel weergegeven.\nDe wizard wordt automatisch geopend voor een nieuw aangemaakte regel - eenmalig, niet voor een dubbele regel. Daarna blijft de wizard beschikbaar in het blokkenpalet.\nDe typeaanduidingen van externe bibliotheken zijn gecorrigeerd: ze werden geplaatst onder de naam die de bibliotheek op de schijf heeft, terwijl hun `package.json` de naam gebruikte die de scripts importeren. Hierdoor werd de verbinding tussen de twee niet tot stand gebracht en was alles wat uit zo'n bibliotheek werd geïmporteerd van het type `any` (#2341).\nHet is niet langer nodig om de declaraties van een bibliotheek in `declare module` te plaatsen, waardoor een barrel-bestand werd afgesneden van wat het opnieuw exporteert. Declaraties die zelf geen module zijn, worden nog steeds in dit geval geplaatst.\nOpgelost probleem met het volgen van imports binnen een declaratiebestand: alleen de eerste import van een bestand werd gevolgd, en alleen als deze op de eerste regel stond. Voor rxjs 6, dat 6 van zijn circa 800 declaratiebestanden laadde.\nNeveneffecten zoals `import \"./x\";` binnen een declaratiebestand worden nu ook gevolgd. `@iobroker/types` bestaat uit niets anders, dus de `ioBroker.*` typen ontbraken in scripts en in de editor.\nEen definitiebestand dat niet kan worden gelezen, verwijdert niet langer alle typedeclaraties van het pakket.\nEr zijn regressietests toegevoegd voor de typeaanduidingen van bibliotheken van derden. Deze tests compileren ertegen en zorgen ervoor dat onjuiste code wordt afgewezen.\n`createState` zet nu de `common.def` van een object-, json- of array-state om in een string, zoals js-controller verwacht en zoals `setState` dat al doet met de waarde. Het aanmaken van een dergelijke state met een initiële waarde geeft niet langer de waarschuwing \"Default value has to be stringified\" (#2307).\nEr is gedocumenteerd dat een object op de tweede positie van `createState` altijd het `common`-object is, en hoe je een state een niet-primitieve beginwaarde kunt geven.\nDe controle van het spiegelpad in de instantieconfiguratie is hersteld. Deze controle was verloren gegaan toen de beheerdersconfiguratie naar `jsonConfig.json` werd verplaatst, waardoor een verboden pad zonder verdere uitleg werd geaccepteerd en pas later in het logboek werd geweigerd (#2296).\nHet veld voor het spiegelpad legt nu uit wat de map moet zijn en geeft een suggestie.\nScripts worden niet langer uit de database verwijderd wanneer de gehele spiegeldirectory onbereikbaar wordt, bijvoorbeeld omdat een gedeelde map niet is aangekoppeld.\nBibliotheken die hun declaraties benoemen via een `exports`-map zijn nu getypeerd. Hun oude `types`-veld is vaak een placeholder die verwijst naar een bestand dat niet bestaat - rxjs 7 is daar een voorbeeld van - waardoor alles wat daaruit werd geïmporteerd als `any` werd beschouwd (#928)\nDe declaraties van een bibliotheek zijn georganiseerd rondom het entry point, waardoor `moduleResolution: node10` deze kan vinden, zelfs als ze zich in een subdirectory bevinden.\nHet manifest dat aan TypeScript werd doorgegeven, beschreef die lay-out in plaats van die op de schijf. Een `exports`-map die verwees naar paden die daar niet bestonden, zorgde ervoor dat TypeScript de bibliotheek volledig weigerde.\nHet package.json-bestand van een bibliotheek wordt van de schijf gelezen in plaats van via Node, dat het bestand weigert als de bibliotheek het niet exporteert.\nDe mirror-tests op macOS zijn gecorrigeerd. Ze reageerden op de eerste gebeurtenis die een watcher meldde, terwijl `fs.watch` daar op mapniveau werkt en een gebeurtenis voor de bewaakte map verzendt vóór die voor het bestand. Ze wachten nu op de wijziging waarover ze gaan en melden wat er is aangekomen als die wijziging niet plaatsvindt.\nDe spiegeltests zijn onafhankelijk gemaakt van de tijd die een watch nodig heeft om te activeren. De te testen wijziging wordt herhaald tijdens het wachten, waardoor deze niet kan worden doorgevoerd voordat de watcher actief is. Dezelfde commit resulteerde in een groene en een rode macOS-taak gedurende die periode.",
+        "fr": "J'ai de nouveau désactivé l'option `strict` pour les scripts, car TypeScript 6 l'active par défaut.\nAjout d'un onglet « TypeScript » aux paramètres, permettant de configurer les options du compilateur pour les scripts.\nAjout de tests de capture d'écran pour la génération de code Blockly (`npm run test:blockly`)\nSuppression de deux marqueurs `.only` résiduels qui avaient désactivé la quasi-totalité de la suite de tests.\nLes fins de ligne des sources TypeScript transformées ont été fixées à LF, afin qu'une mise à jour du compilateur ne puisse pas réécrire chaque script.\nLes micro-benchmarks ont été déplacés dans `npm run test:performance`, car ils mesurent la vitesse relative par rapport aux délais d'attente et ne peuvent pas bloquer une compilation.\nBlockly a été mis à jour de la version 11.1.1 à la version 13.2.1. Le code généré reste inchangé.\n`updateBlockly.js` copie désormais le code depuis le package npm installé au lieu de cloner la branche master de git, ce qui garantit la reproductibilité de la version de Blockly fournie.\nBlockly est désormais intégré au package npm au lieu d'être chargé comme un script externe. Les blocs personnalisés des autres adaptateurs continuent de fonctionner sans modification.\n828 ko de code Blockly externe ont été supprimés du dépôt.\nToutes les définitions de blocs ont été converties de JavaScript en TypeScript. Le code généré reste inchangé.\nCorrection des blocs d'objets sous Blockly 13 : les lignes d'attributs n'étaient plus alignées à droite et la modification des attributs d'un bloc « objet » provoquait une erreur.\nSuppression du code obsolète de l'éditeur de champs CRON et script, qui avait été écrit pour Blockly 1.x.\nCorrection des blocs multi-et/multi-ou sous Blockly 13, qui provoquaient une erreur lors de la modification de leurs conditions.\nSuppression d'un bloc fantôme de type « Convert » enregistré par une affectation parasite dans les blocs de conversion.\nAjout du fichier `BLOCKLY_TS.md` pour les développeurs d'adaptateurs : ce que Blockly 13 a changé pour les blocs personnalisés et comment les écrire en TypeScript.\nJ'ai déplacé les traductions Blockly dans `words.json` et saisi les fonctions d'aide à la recherche.\nRefonte des règles\nUn assistant a été ajouté à l'éditeur de règles. Il permet de créer une règle étape par étape : le déclencheur, la condition et l'action sont configurés directement, et la dernière étape affiche la règle finale.\nL'assistant s'ouvre automatiquement pour une règle nouvellement créée, et non pour une règle dupliquée. Il reste ensuite disponible dans la palette des blocs.\nCorrection des déclarations de type des bibliothèques tierces : elles étaient placées sous le nom de la bibliothèque sur le disque, tandis que leur fichier `package.json` était placé sous le nom importé par les scripts ; par conséquent, TypeScript ne faisait jamais le lien entre les deux et tout ce qui était importé de cette bibliothèque était de type `any` (#2341).\nL'encapsulation des déclarations de bibliothèque dans `declare module` a été supprimée, car elle tronquait le fichier barrel lors de sa réexportation. Les déclarations qui ne sont pas elles-mêmes des modules sont toujours encapsulées.\nCorrection du suivi des importations dans un fichier de déclaration : seule la première importation d'un fichier était prise en compte, et uniquement si elle se trouvait sur la première ligne. Pour RxJS 6, cela concernait 6 de ses quelque 800 fichiers de déclaration.\nLes importations d'effets secondaires (`import \"./x\";`) à l'intérieur d'un fichier de déclaration sont désormais prises en compte. `@iobroker/types` ne contient rien d'autre ; par conséquent, les types `ioBroker.*` étaient absents des scripts et de l'éditeur.\nUn fichier de définition illisible ne supprime plus toutes les déclarations de type de son paquetage\nAjout de tests de régression pour les déclarations de type des bibliothèques tierces, qui compilent par rapport à ces déclarations et exigent que le code incorrect soit rejeté.\nLa méthode `createState` convertit désormais en chaîne de caractères la propriété `common.def` d'un objet, d'un JSON ou d'un tableau d'état, comme l'attend js-controller et comme le fait déjà `setState` avec la valeur. La création d'un tel état avec une valeur initiale ne génère plus l'avertissement « La valeur par défaut doit être convertie en chaîne de caractères » (#2307).\nIl est démontré que l'objet en deuxième position de `createState` est toujours l'objet commun, et il est possible d'attribuer à un état une valeur initiale non primitive.\nLa vérification du chemin du miroir dans la configuration de l'instance a été rétablie. Elle avait disparu lors du déplacement de la configuration d'administration vers `jsonConfig.json`, ce qui avait pour conséquence l'acceptation automatique d'un chemin interdit, lequel n'était refusé que plus tard dans le journal (#2296).\nLe champ « Chemin du miroir » explique désormais quel répertoire doit être indiqué et en suggère un.\nLes scripts ne sont plus supprimés de la base de données lorsque le répertoire miroir devient inaccessible, par exemple parce qu'un partage n'est pas monté.\nLes bibliothèques qui nomment leurs déclarations via une table de correspondance `exports` sont désormais typées. Leur ancien champ `types` était souvent une ébauche pointant vers un fichier inexistant (c'est le cas de rxjs 7), ce qui faisait que toutes les importations depuis ces bibliothèques étaient considérées comme `any` (#928).\nLes déclarations d'une bibliothèque sont disposées autour de son point d'entrée, de sorte que `moduleResolution: node10` la trouve même si elles se trouvent dans un sous-répertoire.\nLe manifeste transmis à TypeScript décrit cette structure au lieu de celle présente sur le disque. Une table de correspondance `exports` pointant vers des chemins inexistants a conduit TypeScript à refuser purement et simplement la bibliothèque.\nLe fichier package.json d'une bibliothèque est lu depuis le disque au lieu d'être traité par Node, qui le refuse si la bibliothèque ne l'exporte pas.\nCorrection des tests de miroirs sur macOS. Ils se déclenchaient au premier événement signalé par un observateur, alors que `fs.watch` fonctionne au niveau du répertoire et envoie un événement pour le répertoire surveillé avant celui du fichier. Désormais, ils attendent la modification attendue et, si celle-ci n'arrive jamais, indiquent ce qui s'est passé.\nLes tests de mise en miroir sont désormais indépendants du temps d'armement de la surveillance. La modification testée est répétée pendant l'attente ; elle ne peut donc pas être effectuée avant que la surveillance ne soit à l'écoute. Le même commit a généré une tâche macOS verte et une tâche macOS rouge.",
+        "it": "Ho disattivato nuovamente la modalità `strict` per gli script, dato che TypeScript 6 la abilita di default.\nÈ stata aggiunta la scheda \"TypeScript\" alle impostazioni, dove è possibile configurare le opzioni del compilatore per gli script.\nAggiunti test di snapshot per la generazione del codice Blockly (`npm run test:blockly`)\nSono stati rimossi due marcatori `.only` residui che avevano disabilitato quasi l'intera suite di test.\nHo bloccato le terminazioni di riga dei sorgenti TypeScript trasformati a LF, in modo che un aggiornamento del compilatore non possa riscrivere ogni script.\nHo spostato i micro-benchmark in `npm run test:performance`, poiché misurano la velocità relativa rispetto ai timeout e non possono bloccare una build\nBlockly è stato aggiornato dalla versione 11.1.1 alla 13.2.1. Il codice generato è rimasto invariato.\n`updateBlockly.js` ora copia dal pacchetto npm installato invece di clonare il ramo master di git, quindi la versione di Blockly distribuita è riproducibile\nBlockly ora è incluso nel pacchetto npm anziché essere caricato come tag script forniti dal fornitore. I blocchi personalizzati di altri adattatori continuano a funzionare senza modifiche.\nRimossi 828 kB di codice Blockly di terze parti dal repository\nTutte le definizioni dei blocchi sono state convertite da JavaScript a TypeScript. Il codice generato è rimasto invariato.\nRisolti i problemi relativi ai blocchi oggetto in Blockly 13: le righe degli attributi non erano più allineate a destra e la modifica degli attributi di un blocco \"oggetto\" generava un errore.\nHo eliminato il codice dell'editor di campi non più necessario per i campi CRON e script, che era stato scritto per Blockly 1.x.\nRisolti i problemi relativi ai blocchi multi-and/multi-or in Blockly 13, che generavano un errore quando le loro condizioni venivano modificate.\nRimosso un blocco fantasma di tipo \"Converti\" che era stato assegnato erroneamente nei blocchi di conversione\nAggiunto il file `BLOCKLY_TS.md` per gli sviluppatori di adattatori: spiega le novità di Blockly 13 relative ai blocchi personalizzati e come scriverli in TypeScript.\nHo spostato le traduzioni di Blockly in `words.json` e ho digitato gli helper di ricerca.\nRiprogettazione delle regole\nÈ stata aggiunta una procedura guidata all'editor delle regole che crea una regola passo dopo passo: trigger, condizione e azione vengono configurati direttamente, e l'ultimo passaggio mostra la regola completata.\nLa procedura guidata si apre automaticamente per una regola appena creata, una sola volta, e non per una regola duplicata. Dopodiché rimane disponibile nella tavolozza dei blocchi.\nCorretti i tipi delle dichiarazioni delle librerie di terze parti: venivano posizionate con il nome che la libreria ha su disco, mentre il loro `package.json` utilizzava il nome che gli script importavano, quindi TypeScript non collegava mai i due e tutto ciò che veniva importato da tale libreria era `any` (#2341)\nÈ stato interrotto l'inserimento delle dichiarazioni di una libreria in `declare module`, che separava il file barrel da ciò che veniva riesportato. Le dichiarazioni che non costituiscono un modulo vengono comunque ancora inserite in questo modo.\nRisolto il problema relativo al monitoraggio delle importazioni all'interno di un file di dichiarazione: veniva seguita solo la prima importazione di un file, e solo se si trovava sulla prima riga. Per rxjs 6 che caricava 6 dei suoi ~800 file di dichiarazione\nAnche le importazioni con effetti collaterali (`import \"./x\";`) all'interno di un file di dichiarazione vengono ora seguite. `@iobroker/types` non contiene altro, quindi i tipi `ioBroker.*` mancavano negli script e nell'editor.\nUn file di definizione che non può essere letto non scarta più tutte le dichiarazioni di tipo del suo pacchetto\nSono stati aggiunti test di regressione per le dichiarazioni di tipo delle librerie di terze parti, che vengono compilate rispetto a tali dichiarazioni e insistono affinché il codice errato venga rifiutato.\n`createState` ora converte in stringa `common.def` di uno stato oggetto, json o array, come previsto da js-controller e come già fa `setState` con il valore. La creazione di tale stato con un valore iniziale non visualizza più l'avviso \"Il valore predefinito deve essere convertito in stringa\" (#2307).\nÈ documentato che un oggetto nella seconda posizione di `createState` è sempre il `common`, e come assegnare a uno stato un valore iniziale non primitivo.\nÈ stato ripristinato il controllo del percorso mirror nella configurazione dell'istanza. Era andato perso quando la configurazione amministrativa è stata spostata in `jsonConfig.json`, quindi un percorso proibito veniva accettato senza alcun avviso e rifiutato solo in seguito nel log (#2296).\nIl campo percorso mirror ora spiega quale deve essere la directory e suggerisce una\nGli script non vengono più eliminati dal database quando l'intera directory mirror diventa irraggiungibile, ad esempio perché una condivisione non è montata.\nLe librerie che denominano le proprie dichiarazioni tramite una mappa `exports` ora sono tipizzate. Il loro vecchio campo `types` è spesso uno stub che punta a un file inesistente - rxjs 7 è uno di questi - il che lasciava tutto ciò che veniva importato da esse come `any` (#928)\nLe dichiarazioni di una libreria sono disposte attorno al suo punto di ingresso, quindi `moduleResolution: node10` lo trova anche quando si trovano in una sottocartella\nIl manifesto consegnato a TypeScript descrive quel layout invece di quello presente su disco. Una mappa `exports` che punta a percorsi inesistenti ha fatto sì che TypeScript rifiutasse completamente la libreria.\nIl file package.json di una libreria viene letto dal disco anziché tramite Node, che lo rifiuta quando la libreria non lo esporta\nCorretti i test mirror su macOS. Prima si verificava un'asserzione sul primo evento segnalato da un watcher, mentre `fs.watch` funziona a livello di directory e invia un evento per la directory monitorata prima di quello per il file. Ora attendono la modifica che stanno per verificare e, se non arriva, segnalano cosa è arrivato.\nI test dello specchio sono stati resi indipendenti dal tempo necessario all'attivazione dell'orologio. La modifica in fase di test viene ripetuta durante l'attesa, quindi non può essere effettuata prima che il watcher sia in ascolto: lo stesso commit ha prodotto un job macOS verde e uno rosso su quello",
+        "es": "Volví a desactivar `strict` para los scripts, ya que TypeScript 6 lo habilita por defecto.\nSe agregó la pestaña \"TypeScript\" a la configuración, donde se pueden configurar las opciones del compilador para los scripts.\nSe agregaron pruebas instantáneas para la generación de código Blockly (`npm run test:blockly`)\nSe eliminaron dos marcadores `.only` sobrantes que habían deshabilitado casi todo el conjunto de pruebas.\nSe fijaron los finales de línea de los archivos fuente TypeScript transformados a LF, por lo que una actualización del compilador no puede reescribir todos los scripts.\nSe han movido las micropruebas a `npm run test:performance`, ya que miden la velocidad relativa frente a los tiempos de espera y no pueden bloquear una compilación.\nSe actualizó Blockly de la versión 11.1.1 a la 13.2.1. El código generado permanece sin cambios.\n`updateBlockly.js` ahora copia desde el paquete npm instalado en lugar de clonar la rama principal de git, por lo que la versión de Blockly distribuida es reproducible.\nBlockly ahora se incluye en el paquete npm en lugar de cargarse como etiquetas de script externas. Los bloques personalizados de otros adaptadores siguen funcionando sin cambios.\nSe eliminaron 828 kB de código Blockly proporcionado por terceros del repositorio.\nSe convirtieron todas las definiciones de bloques de JavaScript a TypeScript. El código generado permanece sin cambios.\nSe corrigieron los bloques de objetos en Blockly 13: las filas de atributos ya no estaban alineadas a la derecha y la edición de los atributos de un bloque \"objeto\" arrojaba\nSe eliminó el código obsoleto del editor de campos CRON y de los campos de script, que había sido escrito para Blockly 1.x.\nSe corrigieron los bloques multi-AND/multi-OR en Blockly 13, que generaban errores al editar sus condiciones.\nSe eliminó un tipo de bloque fantasma \"Convertir\" que había sido registrado por una asignación errónea en los bloques de conversión.\nSe agregó `BLOCKLY_TS.md` para desarrolladores de adaptadores: qué cambió Blockly 13 para los bloques personalizados y cómo escribirlos en TypeScript.\nTrasladé las traducciones de Blockly a `words.json` y escribí los ayudantes de búsqueda.\nRediseño de las reglas\nSe agregó un asistente al editor de reglas que crea una regla paso a paso: el desencadenador, la condición y la acción se configuran en su lugar, y el último paso muestra la regla terminada.\nEl asistente se abre automáticamente para una regla recién creada (una sola vez, no para una duplicada). Posteriormente, permanece disponible en la paleta de bloques.\nSe corrigieron las declaraciones de tipo de las bibliotecas de terceros: se colocaban bajo el nombre que la biblioteca tiene en el disco, mientras que su `package.json` iba al nombre que importaban los scripts, por lo que TypeScript nunca conectaba los dos y todo lo importado de dicha biblioteca era `any` (#2341).\nSe dejó de envolver las declaraciones de una biblioteca en `declare module`, lo que separaba un archivo de barril de lo que reexportaba. Las declaraciones que no son un módulo en sí mismas siguen envueltas.\nSe corrigió el seguimiento de las importaciones dentro de un archivo de declaración: solo se seguía la primera importación de un archivo, y solo si estaba en la primera línea. Para rxjs 6 que cargaba 6 de sus ~800 archivos de declaración.\nLas importaciones de efectos secundarios (`import \"./x\";`) dentro de un archivo de declaración ahora también se siguen. `@iobroker/types` no contiene nada más, por lo que faltaban los tipos `ioBroker.*` en los scripts y en el editor.\nUn archivo de definición que no se puede leer ya no descarta todas las declaraciones de tipo de su paquete.\nSe agregaron pruebas de regresión para las declaraciones de tipo de las bibliotecas de terceros, que compilan contra ellas e insisten en que se rechace el código incorrecto.\n`createState` ahora convierte a cadena `common.def` un objeto, JSON o estado de matriz, tal como lo espera js-controller y como ya lo hace `setState` con el valor. Al crear dicho estado con un valor inicial, ya no aparece la advertencia \"El valor predeterminado debe convertirse a cadena\" (#2307).\nSe documentó que un objeto en la segunda posición de `createState` siempre es el `common`, y cómo darle a un estado un valor inicial no primitivo.\nSe restauró la verificación de la ruta del espejo en la configuración de la instancia. Se perdió cuando la configuración de administración se trasladó a `jsonConfig.json`, por lo que se aceptó una ruta prohibida sin previo aviso y solo se rechazó posteriormente en el registro (#2296).\nEl campo de ruta del espejo ahora explica cuál debe ser el directorio y sugiere uno\nLos scripts ya no se eliminan de la base de datos cuando el directorio espejo en su totalidad deja de ser accesible, por ejemplo, porque un recurso compartido no está montado.\nLas bibliotecas que nombran sus declaraciones mediante un mapa `exports` ahora tienen tipos. Su campo `types` heredado suele ser un stub que apunta a un archivo que no existe (RxJS 7 es un ejemplo), lo que hacía que todo lo importado desde ellas se considerara `any` (#928).\nLas declaraciones de una biblioteca se organizan alrededor de su punto de entrada, por lo que `moduleResolution: node10` la encuentra incluso cuando se encuentran en un subdirectorio.\nEl manifiesto entregado a TypeScript describe esa estructura en lugar de la que se encuentra en el disco. Un mapa `exports` que apunta a rutas que no existen allí provocó que TypeScript rechazara la biblioteca por completo.\nEl archivo package.json de una biblioteca se lee desde el disco en lugar de a través de Node, que lo rechaza cuando la biblioteca no lo exporta.\nSe corrigieron las pruebas de espejo en macOS. Estas afirmaban que en el primer evento reportado por un observador, mientras que `fs.watch` allí funciona a nivel de directorio y envía un evento para el directorio observado antes que el del archivo. Ahora esperan el cambio que están a punto de ocurrir y, en su lugar, indican qué llegó si nunca llega.\nSe hicieron las pruebas de espejo independientes del tiempo que tarda un reloj en armarse. El cambio bajo prueba se repite mientras espera, por lo que no se puede realizar antes de que el observador esté escuchando; la misma confirmación produjo un trabajo de macOS verde y rojo en ese momento.",
+        "pl": "Ponownie wyłączono opcję „strict” dla skryptów, ponieważ TypeScript 6 domyślnie ją włącza\nDodano zakładkę „TypeScript” do ustawień, w której można skonfigurować opcje kompilatora dla skryptów\nDodano testy migawek do generowania kodu Blockly (`npm run test:blockly`)\nUsunięto dwa pozostałe znaczniki `.only`, które wyłączały niemal cały zestaw testów\nPrzypięto zakończenia linii przekształconych źródeł TypeScript do LF, więc aktualizacja kompilatora nie może przepisać każdego skryptu\nPrzeniesiono mikrotesty do `npm run test:performance`, ponieważ mierzą one względną prędkość w stosunku do przekroczeń limitu czasu i nie mogą blokować kompilacji\nZaktualizowano Blockly z wersji 11.1.1 do 13.2.1. Wygenerowany kod pozostaje niezmieniony.\n`updateBlockly.js` teraz kopiuje z zainstalowanego pakietu npm zamiast klonować gałąź git master, dzięki czemu dostarczona wersja Blockly jest możliwa do odtworzenia\nBlockly jest teraz dołączony do pakietu npm, a nie ładowany jako tagi skryptów dostawcy. Niestandardowe bloki innych adapterów działają bez zmian.\nUsunięto 828 kB dostarczonego kodu Blockly z repozytorium\nPrzekonwertowano wszystkie definicje bloków z JavaScript na TypeScript. Wygenerowany kod pozostaje niezmieniony.\nNaprawiono bloki obiektów w Blockly 13: wiersze atrybutów nie były już wyrównane do prawej, a edycja atrybutów bloku „obiekt” powodowała\nUsunięto martwy kod edytora pól CRON i skryptów, który został napisany dla Blockly 1.x\nNaprawiono bloki multi-and/multi-or w Blockly 13, które pojawiały się podczas edycji ich warunków\nUsunięto blok fantomowy typu „Konwertuj”, który został zarejestrowany przez przypadkowe przypisanie w blokach konwersji\nDodano `BLOCKLY_TS.md` dla programistów adapterów: co Blockly 13 zmieniło w przypadku bloków niestandardowych i jak je pisać w TypeScript\nPrzeniesiono tłumaczenia Blockly do pliku `words.json` i wpisano pomocniki wyszukiwania\nPrzeprojektowanie zasad\nDodano kreatora do edytora reguł, który tworzy regułę krok po kroku – wyzwalacz, warunek i działanie są konfigurowane na miejscu, a ostatni krok pokazuje gotową regułę\nKreator otwiera się automatycznie dla nowo utworzonej reguły – raz, a nie dla duplikatu. Następnie pozostaje on dostępny w palecie bloków.\nNaprawiono deklaracje typu bibliotek zewnętrznych: umieszczano je pod nazwą, jaką biblioteka ma na dysku, podczas gdy ich `package.json` trafiał pod nazwę importowanych skryptów, więc TypeScript nigdy nie łączył tych dwóch plików, a wszystko, co importowano z takiej biblioteki, brzmiało `any` (#2341)\nZaprzestano pakowania deklaracji biblioteki w „declare module”, co oddzielało plik beczkowy od tego, co reeksportuje. Deklaracje, które same w sobie nie są modułem, nadal są pakowane.\nNaprawiono śledzenie importów w pliku deklaracji: śledzony był tylko pierwszy import pliku i tylko wtedy, gdy znajdował się on w pierwszym wierszu. W przypadku rxjs 6, który ładował 6 z ~800 plików deklaracji.\nImporty efektów ubocznych (`import \"./x\";`) w pliku deklaracji są teraz również uwzględniane. `@iobroker/types` nie składa się z niczego innego, więc typy `ioBroker.*` nie były widoczne w skryptach i edytorze.\nPlik definicji, którego nie można odczytać, nie odrzuca już wszystkich deklaracji typu swojego pakietu\nDodano testy regresji dla deklaracji typów bibliotek stron trzecich, które kompilują się względem nich i nalegają na odrzucenie niewłaściwego kodu\nFunkcja `createState` przekształca teraz stan obiektu, JSON lub tablicy w ciąg `common.def`, tak jak oczekuje tego kontroler js i jak funkcja `setState` już to robi z wartością. Utworzenie takiego stanu z wartością początkową nie powoduje już wyświetlania ostrzeżenia „Wartość domyślna musi być przekształcona w ciąg” (#2307).\nUdokumentowano, że obiekt na drugiej pozycji `createState` jest zawsze `wspólny`, a także jak nadać stanowi wartość początkową nieprymitywną\nPrzywrócono sprawdzanie ścieżki lustrzanej w konfiguracji instancji. Została ona utracona po przeniesieniu konfiguracji administratora do pliku `jsonConfig.json`, więc zabroniona ścieżka została zaakceptowana bez słowa i odrzucona dopiero później w logu (#2296).\nPole ścieżki lustrzanej teraz wyjaśnia, jaki powinien być katalog i sugeruje jeden\nSkrypty nie są już usuwane z bazy danych, gdy cały katalog lustrzany staje się niedostępny, np. z powodu braku zamontowania udziału\nBiblioteki, które nazywają swoje deklaracje za pomocą mapy `exports`, są teraz typizowane. Ich starsze pole `types` często jest szczątkiem wskazującym na plik, który nie istnieje – rxjs 7 jest jednym z nich – przez co wszystko, co jest z nich importowane, pozostaje jako `any` (#928).\nDeklaracje biblioteki są rozmieszczone wokół jej punktu wejścia, więc `moduleResolution: node10` znajdzie ją nawet wtedy, gdy znajduje się ona w podkatalogu\nManifest przekazany TypeScript opisuje ten układ zamiast tego na dysku. Mapa „exports” wskazująca na ścieżki, które tam nie istnieją, spowodowała, że TypeScript całkowicie odrzucił bibliotekę.\nPlik package.json biblioteki jest odczytywany z dysku, a nie przez Node, który go odrzuca, gdy biblioteka go nie eksportuje\nNaprawiono testy lustrzane na macOS. Potwierdzono pierwsze zdarzenie zgłoszone przez obserwatora, podczas gdy `fs.watch` działa z dokładnością do katalogu i wysyła zdarzenie dla obserwowanego katalogu przed zdarzeniem dla pliku. Teraz czekają na zmianę, której dotyczą, i zamiast tego informują o tym, co nastąpiło, jeśli nigdy nie nastąpi.\nUniezależniono testy lustrzane od czasu uzbrajania zegarka. Testowana zmiana jest powtarzana w trakcie oczekiwania, więc nie można jej wprowadzić, zanim obserwator nie zacznie nasłuchiwać – to samo zatwierdzenie spowodowało zielone i czerwone zadanie macOS.",
+        "uk": "Знову вимкнув `strict` для скриптів, оскільки TypeScript 6 увімкнув його за замовчуванням\nДо налаштувань додано вкладку \"TypeScript\", де можна налаштувати параметри компілятора для скриптів.\nДодано тести-знімки для генерації коду Blockly (`npm run test:blockly`)\nВидалено два залишкові маркери `.only`, які вимкнули майже весь набір тестів\nЗакріплено закінчення рядків перетворених вихідних кодів TypeScript до LF, щоб оновлення компілятора не могло переписати кожен скрипт.\nМікро-бенчмарки перенесено до `npm run test:performance`, оскільки вони вимірюють відносну швидкість відносно тайм-аутів і не можуть блокувати збірку.\nОновлено Blockly з версії 11.1.1 до 13.2.1. Згенерований код залишився без змін.\n`updateBlockly.js` тепер копіюється з встановленого npm-пакета замість клонування гілки git master, тому постачальник Blockly-версію можна відтворювати.\nBlockly тепер постачається з пакета npm, а не завантажується як теги скриптів від виробника. Користувацькі блоки інших адаптерів працюють без змін.\nВидалено 828 КБ коду Blockly від вендорів з репозиторію\nКонвертовано всі визначення блоків з JavaScript у TypeScript. Згенерований код не змінився.\nВиправлено блоки об'єктів у Blockly 13: рядки атрибутів більше не вирівнювалися по правому краю, а редагування атрибутів блоку \"об'єкта\" призводило до\nВидалено непрацюючий код редактора полів CRON та скриптів, який був написаний для Blockly 1.x.\nВиправлено блоки типу «мульти-та/мульти-або» в Blockly 13, які виникали під час редагування їхніх умов.\nВидалено фантомний блок типу \"Convert\", який був зареєстрований випадковим призначенням у блоках перетворення.\nДодано `BLOCKLY_TS.md` для розробників адаптерів: що змінив Blockly 13 для користувацьких блоків та як їх писати в TypeScript.\nПереміщено переклади Blockly у `words.json` та введено помічники пошуку\nПереробка правил\nДо редактора правил додано майстер, який крок за кроком створює правило — тригер, умова та дія налаштовуються, а на останньому кроці відображається готове правило.\nМайстер відкривається самостійно для щойно створеного правила – один раз, а не для дубліката. Після цього він залишається доступним у палітрі блоків.\nВиправлено оголошення типів сторонніх бібліотек: вони розміщувалися під назвою бібліотеки на диску, тоді як їхній `package.json` передавався під назвою, яку імпортують скрипти, тому TypeScript ніколи не пов'язував ці два типи, і все, що імпортувалося з такої бібліотеки, було `any` (#2341)\nПрипинено обгортання оголошень бібліотеки в `declare module`, що відрізало файл типу \"barrel\" від того, що він реекспортує. Оголошення, які самі по собі не є модулями, все ще обгортаються.\nВиправлено помилку, пов'язану з імпортом у файлі оголошення: відстежувався лише перший імпорт файлу, і лише якщо він був у першому рядку. Для rxjs 6, який завантажував 6 з ~800 файлів оголошення.\nІмпорт побічних ефектів (`import \"./x\";`) всередині файлу оголошення тепер також виконується. `@iobroker/types` більше нічого не містить, тому типи `ioBroker.*` були відсутні у скриптах та редакторі.\nФайл визначення, який неможливо прочитати, більше не відкидає всі оголошення типів свого пакета.\nДодано регресійні тести для оголошень типів сторонніх бібліотек, які компілюються відповідно до них та наполягають на відхиленні неправильного коду.\n`createState` тепер перетворює `common.def` стану об'єкта, json або масиву в рядок, як очікує js-controller, і як `setState` вже робить зі значенням. Створення такого стану з початковим значенням більше не попереджає \"Значення за замовчуванням має бути перетворене в рядок\" (#2307)\nЗадокументовано, що об'єкт у другій позиції `createState` завжди є `common`, і як надати стану непримітивне початкове значення\nВідновлено перевірку шляху дзеркала в конфігурації екземпляра. Вона була втрачена, коли конфігурація адміністратора перемістилася до `jsonConfig.json`, тому заборонений шлях приймався без жодних слів і лише пізніше відхилявся в журналі (#2296)\nПоле шляху дзеркала тепер пояснює, яким має бути каталог, і пропонує один із варіантів.\nСкрипти більше не видаляються з бази даних, коли каталог дзеркала в цілому стає недоступним, наприклад, через те, що спільний ресурс не змонтовано.\nБібліотеки, які іменують свої оголошення через карту `exports`, тепер типізовані. Їхнє застаріле поле `types` часто є заглушкою, що вказує на файл, якого не існує — rxjs 7 є однією з них — що залишало все, що імпортувалося з них, як `any` (#928)\nОголошення бібліотеки розташовані навколо її точки входу, тому `moduleResolution: node10` знаходить її, навіть якщо вона знаходиться в підкаталозі\nМаніфест, переданий TypeScript, описує цей макет, а не той, що на диску. Карта `exports`, що вказує на шляхи, яких там не існує, змусила TypeScript взагалі відмовитися від бібліотеки.\nФайл package.json бібліотеки зчитується з диска, а не через Node, який відхиляє його, коли бібліотека не експортує його.\nВиправлено дзеркальні тести на macOS. Вони стверджували першу подію, про яку повідомляв спостерігач, тоді як `fs.watch` там працює на рівні деталізації каталогів і надсилає подію для спостеріганого каталогу перед подією для файлу. Тепер вони чекають на зміну, про яку йдеться, і повідомляють, що надійшло, якщо вона так і не настала.\nЗроблено тести дзеркала незалежними від того, скільки часу потрібно годиннику для активації. Тестована зміна повторюється під час очікування, тому її не можна внести до того, як спостерігач почне слухати - той самий коміт створив зелене та червоне завдання macOS над цим.",
+        "zh-cn": "已再次关闭脚本的 `strict` 属性，因为 TypeScript 6 默认启用该属性。\n设置中新增了“TypeScript”选项卡，可以在其中配置脚本的编译器选项。\n为 Blockly 代码生成添加了快照测试（`npm run test:blockly`）\n移除了两个残留的 `.only` 标记，它们几乎禁用了整个测试套件。\n将转换后的 TypeScript 源文件的行尾固定为 LF，这样编译器更新就不会重写每个脚本。\n已将微基准测试移至 `npm run test:performance` 中，因为它们衡量的是相对于超时的相对速度，并且不会阻塞构建过程。\nBlockly 已从 11.1.1 更新至 13.2.1。生成的代码未作更改。\n`updateBlockly.js` 现在从已安装的 npm 包复制代码，而不是克隆 git master 分支，因此发布的 Blockly 版本是可复现的。\nBlockly 现在已通过 npm 包打包，不再作为 vendored 脚本标签加载。其他适配器的自定义代码块将继续正常工作，无需任何更改。\n从代码库中移除了 828 kB 的 Blockly 代码库自带代码\n已将所有代码块定义从 JavaScript 转换为 TypeScript。生成的代码保持不变。\n修复了 Blockly 13 下的对象块问题：属性行不再右对齐，并且编辑“对象”块的属性时会抛出异常。\n删除了 CRON 和脚本字段中已失效的字段编辑器代码，这些代码是针对 Blockly 1.x 编写的。\n修复了 Blockly 13 中多对多/多或模块在编辑其条件时会抛出的错误。\n移除了一个虚幻的“转换”块类型，该类型是由转换块中一个错误的赋值操作注册的。\n为适配器开发者添加了 `BLOCKLY_TS.md` 文件：其中介绍了 Blockly 13 对自定义块的更改以及如何在 TypeScript 中编写它们。\n将 Blockly 翻译移至 `words.json` 文件中，并输入了查找辅助函数。\n规则重新设计\n在规则编辑器中添加了一个向导，可以逐步构建规则——触发器、条件和操作都会预先配置好，最后一步会显示最终的规则。\n对于新创建的规则，向导会自动打开——仅打开一次，重复创建的规则则不会。之后，它会一直保留在模块面板中。\n修复了第三方库的类型声明：它们被放置在库在磁盘上的名称下，而它们的 `package.json` 却使用了脚本导入的名称，因此 TypeScript 从未将两者关联起来，从这类库导入的所有内容都是 `any` 类型 (#2341)\n不再将库的声明包装在 `declare module` 中，这导致桶形文件与它重新导出的内容分离。非模块本身的声明仍然会被包装。\n修复了声明文件中导入语句的执行问题：之前只执行文件中的第一个导入语句，且仅当它位于第一行时才会执行。此问题已在 rxjs 6 中修复，该版本加载了约 800 个声明文件中的 6 个。\n现在，声明文件中的副作用导入（`import \"./x\";`）也会被处理。`@iobroker/types` 目录下没有其他内容，因此脚本和编辑器中缺少 `ioBroker.*` 类型。\n无法读取的定义文件不再丢弃其包的所有类型声明\n为第三方库的类型声明添加了回归测试，这些测试会针对这些库进行编译，并坚持拒绝错误的代码。\n现在，`createState` 会将对象、JSON 或数组状态的 `common.def` 字符串化，这符合 js-controller 的预期，也与 `setState` 对值的处理方式一致。使用初始值创建此类状态时，不再会发出“默认值必须字符串化”的警告 (#2307)。\n文档中说明 `createState` 函数中第二个位置的对象始终是 `common`，以及如何为状态赋予非原始类型的初始值。\n恢复了实例配置中镜像路径的检查。由于管理配置迁移到 `jsonConfig.json` 文件后，该检查丢失了，导致未经任何提示就接受了禁止的路径，直到日志中才记录了拒绝操作 (#2296)。\n镜像路径字段现在解释了目录必须是什么，并给出了一个建议。\n当整个镜像目录无法访问时（例如，由于共享未挂载），脚本不再从数据库中删除。\n现在，通过 `exports` 映射表命名其声明的库都已类型化。它们遗留的 `types` 字段通常是一个指向不存在文件的存根——rxjs 7 就是一个例子——这导致从它们导入的所有内容都被视为 `any` 类型 (#928)。\n库的声明都围绕其入口点布局，因此即使它们位于子目录中，`moduleResolution: node10` 也能找到它。\n传递给 TypeScript 的清单文件描述的是磁盘上的布局，而不是实际的磁盘布局。一个指向不存在路径的 `exports` 映射导致 TypeScript 完全拒绝了该库。\n库的 package.json 文件是从磁盘读取的，而不是通过 Node 读取的，因此当库没有导出 package.json 文件时，Node 会拒绝读取该文件。\n修复了 macOS 上的镜像测试。之前，这些测试会在监视器报告的第一个事件发生时进行断言，而 macOS 上的 `fs.watch` 实际上是按目录粒度工作的，它会在文件事件之前先发送被监视目录的事件。现在，这些测试会等待目标更改发生，如果更改始终没有发生，则会报告已到达的内容。\n镜像测试不再受手表启动时间的影响。被测更改会在等待期间重复执行，因此必须在手表监听后才能进行——同一次提交在 macOS 上产生了绿色和红色两种结果。"
+      },
       "10.0.0": {
         "en": "Typescript 6 support\nGUI was migrated to React 19 and MUI 9\nShowed host name in the instance selection dialog",
         "de": "TypeScript 6-Unterstützung\nDie Benutzeroberfläche wurde auf React 19 und MUI 9 migriert.\nDer Hostname wurde im Instanzauswahldialog angezeigt.",
@@ -104,32 +130,6 @@
         "pl": "Optymalizacja wykonania\nDodano na myszce nad wartością stanu",
         "uk": "Оптимізація продуктивності\nДодано на мишу над значенням держави",
         "zh-cn": "业绩优化\n在鼠标上大于状态值"
-      },
-      "9.2.2": {
-        "en": "Fix: AI chat mode tooltip no longer covers the dropdown options (issue #2201) — moved tooltip to the left of the selector\nClarified the AI chat mode descriptions in the tooltip: Agent is for larger models with tool support and handles both analysis and script creation, Code is for smaller models without tool support (uses two-step plan-then-code) — translations updated in all 11 languages\nAdded the \"is state exists\" block to blockly",
-        "de": "Fix: AI-Chat-Modus-Tooltip nicht mehr deckt die Dropdown-Optionen (Ausgabe #2201) - verschoben Tooltip auf die linke Seite des Selektors\nKI-Chat-Modus Beschreibungen im Tooltip: Agent ist für größere Modelle mit Werkzeugunterstützung und behandelt sowohl Analyse als auch Skript-Erstellung, Code ist für kleinere Modelle ohne Werkzeugunterstützung (verwendet zweistufigen Plan-then-Code) — Übersetzungen aktualisiert in allen 11 Sprachen\nDer \"is state exist\" Block wurde blockweise hinzugefügt",
-        "ru": "Исправление: инструментарий режима чата AI больше не покрывает выпадающие опции (выпуск #2201) — перемещаемый инструментарий слева от селектора\nУточнено описание режима чата ИИ в подсказке: Агент предназначен для более крупных моделей с поддержкой инструментов и обрабатывает как анализ, так и создание сценариев, Код предназначен для более мелких моделей без поддержки инструментов (использует двухэтапный план-тогда-код) — переводы обновлены на всех 11 языках\nДобавлен блок «существует государство» для блокировки",
-        "pt": "Corrigir: A dica do modo de bate-papo de IA não cobre mais as opções suspensas (questão # 2201) — moveu a dica para a esquerda do seletor\nClarified the AI chat mode descriptions in the tooltip: Agent is for major models with tool support and hands both analysis and script creation, Code is for minor models without toool support (uses two-step plan-then-code) — translations updated in all 11 languages\nAdicionado o bloco \"is state existe\" para bloquear",
-        "nl": "Fix: AI chat mode tooltip heeft geen betrekking meer op de dropdown opties (issue #2201)\nVerduidelijkt de AI chat mode beschrijvingen in de tooltip: Agent is voor grotere modellen met hulpmiddel ondersteuning en behandelt zowel analyse als script creatie, Code is voor kleinere modellen zonder hulpmiddel ondersteuning (gebruikt twee-stap plan-dan-code) Vertalingen bijgewerkt in alle 11 talen\nToegevoegd de \"is status bestaat\" blok te blokkeren",
-        "fr": "Correction : l'outil en mode chat AI ne couvre plus les options déroulantes (numéro #2201) — l'outil déplacé à gauche du sélecteur\nClarifié les descriptions des modes de chat AI dans l'infobulle : Agent est pour les modèles plus grands avec support d'outil et gère à la fois l'analyse et la création de script, Code est pour les modèles plus petits sans support d'outil (utilise le plan en deux étapes - puis-code) — traductions mises à jour dans les 11 langues\nAjout du bloc « is state exists » pour bloquer",
-        "it": "Fix: AI chat mode tooltip non copre più le opzioni di discesa (problema #2201) — spostato tooltip a sinistra del selettore\nClarified le descrizioni della modalità di chat AI nel tooltip: L'agente è per i modelli più grandi con supporto degli strumenti e gestisce sia l'analisi che la creazione di script, il codice è per i modelli più piccoli senza supporto degli strumenti (utilizza il codice a due passi) — le traduzioni aggiornate in tutte le 11 lingue\nAggiunto il blocco \"è stato esiste\" per bloccare",
-        "es": "Fijación: El uso de herramientas de modo de chat AI ya no cubre las opciones desplegables (sue #2201) — mover la punta de la herramienta a la izquierda del selector\nClarified the AI chat mode descriptions in the tooltip: Agent is for larger models with tool support and handles both analysis and script creation, Code is for smaller models without tool support (uses two-step plan-then-code) — translations updated in all 11 languages\nAñadido el bloque \"es estado existe\" para bloquear",
-        "pl": "Fix: AI chat mode tooltip już nie obejmuje opcji Dropdown (issue # 2201) - przesunięty podpowiedź po lewej stronie selektora\nWyjaśnienie opisów trybu rozmowy AI w podpowiedzi: Agent jest dla większych modeli z obsługą narzędzi i obsługuje zarówno analizy i tworzenia skryptów, Kod jest dla mniejszych modeli bez obsługi narzędzia (używa dwustopniowej plan- theen- code) - tłumaczenia zaktualizowane we wszystkich 11 językach\nDodano blokadę \"is state istnieje\"",
-        "uk": "Виправлення: Інструментарій режимів AI не більше охоплює параметри випадання (видання #2201) — пересувний інструмент для ліворуч від selector\nНаведено описи режиму AI чату в інструменті: Агент призначений для збільшення моделей з підтримкою інструментів і ручками як аналізу, так і для створення сценаріїв, Код є для менших моделей без підтримки інструменту ( використовує двокроковий план-фін-код) — переклади, оновлено у всіх 11 мовах\nДодано блок-блок \"is State існує\"",
-        "zh-cn": "固定:AI聊天模式工具提示不再覆盖下拉选项(问题#2201)——移动工具提示到选择器左侧\n整理工具提示中的 AI 聊天模式描述 : Agent 用于具有工具支持的较大模型,并同时处理分析和脚本创建, Code 用于没有工具支持的较小模型(使用双步计划-当时的代码)——所有11种语言的翻译更新\n添加“ 状态存在” 块以阻断"
-      },
-      "9.2.1": {
-        "en": "See previous changelog entries",
-        "de": "Siehe frühere Changelog-Einträge",
-        "ru": "См. предыдущие Changelog",
-        "pt": "Ver entradas anteriores do changelog",
-        "nl": "Zie vorige wijzigingenlog items",
-        "fr": "Voir les entrées précédentes du journal des modifications",
-        "it": "Vedere le precedenti voci di changelog",
-        "es": "Ver entradas de cambio anteriores",
-        "pl": "Zob. poprzednie wpisy dotyczące zmiennych",
-        "uk": "Переглянути попередні записи змін",
-        "zh-cn": "参见上一个更改日志条目"
       }
     },
     "platform": "Javascript/Node.js",
@@ -525,6 +525,7 @@
     "enableSetObject": false,
     "enableSendToHost": false,
     "enableExec": false,
+    "enableSecrets": true,
     "libraries": "",
     "libraryTypings": "",
     "subscribe": false,
@@ -554,7 +555,37 @@
     "credentialIdClaudeKey": "",
     "credentialIdGeminiKey": "",
     "credentialIdDeepseekKey": "",
-    "credentialIdGptBaseUrlKey": ""
+    "credentialIdGptBaseUrlKey": "",
+    "tsTarget": "es2022",
+    "tsStrict": false,
+    "tsNoImplicitAny": "",
+    "tsStrictNullChecks": "",
+    "tsStrictFunctionTypes": "",
+    "tsStrictBindCallApply": "",
+    "tsStrictPropertyInitialization": "",
+    "tsStrictBuiltinIteratorReturn": "",
+    "tsNoImplicitThis": "",
+    "tsAlwaysStrict": "",
+    "tsUseUnknownInCatchVariables": "false",
+    "tsNoUnusedLocals": false,
+    "tsNoUnusedParameters": false,
+    "tsNoImplicitReturns": false,
+    "tsNoFallthroughCasesInSwitch": false,
+    "tsNoImplicitOverride": false,
+    "tsNoUncheckedIndexedAccess": false,
+    "tsNoPropertyAccessFromIndexSignature": false,
+    "tsExactOptionalPropertyTypes": false,
+    "tsAllowUnreachableCode": "",
+    "tsAllowUnusedLabels": "",
+    "tsNoEmitOnError": true,
+    "tsEsModuleInterop": true,
+    "tsAllowSyntheticDefaultImports": false,
+    "tsUseDefineForClassFields": false,
+    "tsDownlevelIteration": false,
+    "tsExperimentalDecorators": false,
+    "tsEmitDecoratorMetadata": false,
+    "tsRemoveComments": false,
+    "tsSkipLibCheck": false
   },
   "encryptedNative": [
     "gptKey",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "iobroker.javascript",
-  "version": "10.0.0",
+  "version": "10.1.1",
   "description": "Rules Engine for ioBroker",
   "author": "bluefox <dogafox@gmail.com>",
   "contributors": [
@@ -49,7 +49,7 @@
     "jszip": "^3.10.1",
     "node-inspect": "^2.0.0",
     "node-schedule": "2.1.1",
-    "nodemailer": "^9.0.3",
+    "nodemailer": "^9.0.5",
     "prettier": "^3.9.6",
     "promisify-child-process": "^5.0.1",
     "semver": "^7.8.5",
@@ -65,13 +65,15 @@
     "@iobroker/adapter-dev": "^1.5.0",
     "@iobroker/build-tools": "^3.0.1",
     "@iobroker/eslint-config": "^2.3.4",
-    "@iobroker/plugin-sentry": "^3.1.2",
+    "@iobroker/plugin-sentry": "^3.2.0",
     "@iobroker/testing": "^5.3.0",
+    "@tsconfig/node22": "^22.0.6",
     "@types/node-schedule": "^2.1.8",
     "@types/nodemailer": "^8.0.1",
     "@types/request": "^2.48.13",
     "@types/suncalc": "^1.9.2",
     "alcalzone-shared": "^5.0.0",
+    "jsdom": "^30.0.1",
     "timekeeper": "^2.3.1"
   },
   "bugs": {
@@ -92,6 +94,9 @@
     "test:integration": "mocha --exit",
     "test:package": "mocha test/testPackageFiles.js --exit",
     "test:scheduler": "mocha test/testScheduler.js --exit",
+    "test:blockly": "mocha test/testBlocklyGenerator.js --exit",
+    "test:performance": "mocha --no-config --require ./test/mocha.setup.js \"test/*.test.js\" test/testMainPerformance.js --exit",
+    "test:blockly:update": "node test/blockly/update.js",
     "test": "npm run test:declarations && npm run test:integration",
     "translate": "translate-adapter",
     "//postinstall": "node ./install/installTypings.js",