lakutata 3.1.4 → 3.1.6

package/doc/en/ContainerdIntegration.md

@@ -15,7 +15,7 @@ The containers it creates are the same as the containers nerdctl creates: they c
 
 | Feature | Needs |
 |---|---|
-| Everything | Linux, containerd 1.6 or later with runc, Node.js `^22.13.0 || >=24.11.0`; the application runs as root or as a member of the group owning the socket of containerd |
+| Everything | Linux, containerd 1.6 or later with runc, Node.js `>=18.10.0`; the application runs as root or as a member of the group owning the socket of containerd |
 | CNI networks (the default `bridge` included), published ports | The CNI plugins (`bridge`, `portmap`, `host-local`… in `/opt/cni/bin`, `/usr/lib/cni` or `/usr/libexec/cni`, the `cniPath` option) and iptables |
 | `exec()` with `stdin`, separate `stdout`/`stderr`, terminals | `mkfifo` on the host (without it, `exec()` puts both outputs in `stdout`) |
 | Builds | A BuildKit daemon (`buildkitd`), local or remote |

package/doc/en/Database.md

@@ -103,6 +103,10 @@ The options are the ones of TypeORM, given to it as they are. The options of eac
 finds the first row of the table: check the values taken from a request before querying with them, or set
 `invalidWhereValuesBehavior: {undefined: 'throw'}` to throw on them (each key given replaces its default).
 
+**Paths with aliases.** A path given with an alias of the application (`@data/app.sqlite`, `@app/migrations/*.js`) is
+resolved when the database connects: the file of the database (`database`, the `location` of sql.js) and the globs of
+the entities, the migrations and the subscribers. The aliases are declared by `.alias()` ([Application](Application.md), section 2).
+
 **Databases created with TypeORM 0.3.** If a table or column name has characters outside ASCII, TypeORM 1 names its
 indices and constraints differently, and generated migrations would rename them.
 `namingStrategy: new NamingStrategyV03()` (from `lakutata/orm`) keeps the names of TypeORM 0.3.

package/doc/en/DatabaseDrivers.md

@@ -23,8 +23,9 @@ npm install lakutata pg
 ```
 
 There is no `sqlite` type: SQLite files use `better-sqlite3`, or `sqljs` where a native module cannot run. TypeORM also
-has drivers for the mobile platforms (`capacitor`, `cordova`, `expo`, `nativescript`, `react-native`); lakutata does
-not target them.
+has drivers for the JavaScript of the mobile platforms (`capacitor`, `cordova`, `expo`, `nativescript`, `react-native`);
+lakutata does not use them. A mobile application of the `mobile-react` template runs the lakutata application in a
+Node.js instead, with the drivers of this page (see [The mobile applications](#the-mobile-applications)).
 
 ## What applies to every driver
 
@@ -136,8 +137,14 @@ export const db = buildDatabaseOptions({
 - The foreign keys are enforced (`PRAGMA foreign_keys = ON`). There is one connection: `poolSize` is not supported.
 - **`bigint` columns come back as numbers**: values beyond 2^53 lose precision. Keep such values in a text column.
 - `better-sqlite3` is a native module, compiled for one version of Node.js. An Electron application needs the build of
-  its Electron (`electron-rebuild`, or the prebuilt binaries of better-sqlite3 for Electron); Bun cannot load it (use
-  `sqljs` there).
+  its Electron (`electron-rebuild`, or the prebuilt binaries of better-sqlite3 for Electron); an NW.js application has
+  it built again with the headers of NW.js (0.111.3 or later: use `sqljs` with the earlier releases); Bun cannot load it
+  (use `sqljs` there).
+- Built from its sources against the headers of Node.js 24.19 or later, it aborts the process when the garbage collector
+  frees one of its objects (`Assertion failed: (env) != nullptr`, in `RemoveEnvironmentCleanupHook`:
+  [nodejs/node#65446](https://github.com/nodejs/node/issues/65446)), as every addon built on `node::ObjectWrap` does.
+  Its prebuilt binaries are built against earlier headers; `lakutata mobile stage` builds the addons for the mobile
+  systems without the cleanup hooks of `node::ObjectWrap` that cause it.
 
 ## SQLite: sql.js
 
@@ -164,6 +171,7 @@ export const db = buildDatabaseOptions({
 | `database` | | The content of a database to load (a `Uint8Array`), instead of `location` |
 | `useLocalForage` | `false` | In a browser, save to IndexedDB (through `localforage`) instead of `localStorage` |
 | `sqlJsConfig` | | The options of the initialization of sql.js (`locateFile` of its `.wasm` file) |
+| `driver` | | A build of sql.js to use instead of the package's: its asm.js build (`sql.js/dist/sql-asm.js`) needs no WebAssembly |
 
 - Without `autoSave`, nothing is written to disk until `saveDatabase()` of the entity manager (`SqljsEntityManager`)
   is called. With `autoSave`, the changes of a transaction are saved once it is committed.
@@ -285,3 +293,66 @@ These drivers come from TypeORM as they are:
   MySQL, are not read.
 - **Amazon Aurora through the Data API** (`aurora-mysql`, `aurora-postgres`): `region`, `secretArn`, `resourceArn` and
   `database` are required; the queries go through the HTTP API of AWS, not through a connection.
+
+## The mobile applications
+
+A mobile application of the `mobile-react` template runs its lakutata application in the Node.js it embeds (Node.js
+24.20), where the drivers of this page work as on a computer. The table gives what was verified on the emulators of
+Android (API 36), iOS (27.2) and HarmonyOS: a database written, closed, then opened again.
+
+| Driver | Android | iOS | HarmonyOS |
+|---|---|---|---|
+| `better-sqlite3` | Yes | Yes | Yes |
+| `sqljs`, its asm.js build | Yes | Yes | Yes |
+| `sqljs`, its WebAssembly | Yes | Yes, much slower (the polyfill: 1.5 s where the asm.js build took 0.09 s) | No: `ReferenceError: WebAssembly is not defined` |
+| `mongo-embedded` | Yes | Yes | Yes |
+| `postgres`, `mysql`, `mongodb` (a server on the network) | Yes | Yes | Yes |
+
+SQL Server and Oracle have not been checked there.
+
+- `lakutata mobile stage` builds `better-sqlite3` from its sources for each system, with the NDK, Xcode or DevEco Studio
+  (see the `lakutata mobile` commands in the README of `@lakutata/cli`).
+- The file of a database has to last, and `os.tmpdir()` is the cache of the application, which the system may empty. The
+  `App.ts` of the template declares the data directory of the application as the alias `@data`: the `files` directory of
+  the application on Android, `Library/Application Support` on iOS, `/data/storage/el2/base/files` on HarmonyOS, and
+  `packages/app/data` on the computer of the development. The options of the database name a file there as
+  `@data/app.sqlite`: the alias is resolved when the database connects.
+- The asm.js build of sql.js is SQLite compiled to JavaScript: no WebAssembly and no other file, so it runs the same on
+  the three systems. The Node.js of HarmonyOS has no WebAssembly, and the one of iOS has only the polyfill of
+  nodejs-mobile, which is much slower:
+
+```typescript
+import type {ApplicationOptions} from 'lakutata'
+import {buildDatabaseOptions} from 'lakutata/com/database'
+import {createRequire} from 'node:module'
+
+/**
+ * The options of the application
+ */
+export function config(): ApplicationOptions {
+    return {
+        id: 'app',
+        name: 'app',
+        components: {
+            db: buildDatabaseOptions({
+                type: 'sqljs',
+                location: '@data/app.sqlite',
+                autoSave: true,
+                //The asm.js build of sql.js, instead of its WebAssembly
+                driver: createRequire(import.meta.url)('sql.js/dist/sql-asm.js'),
+                entities: []
+            })
+        }
+    }
+}
+```
+
+- sql.js 1.15 marks its asm.js build as deprecated: the build prints a warning each time it is loaded, and the authors
+  ask the users who cannot leave it to say so ([sql-js/sql.js#635](https://github.com/sql-js/sql.js/issues/635)). The
+  build they recommend instead, `sql-wasm-inline.js`, needs WebAssembly, which the Node.js of HarmonyOS does not have.
+  For a database that the application keeps, `better-sqlite3`, which works on the three systems, is the better choice.
+- The WebAssembly of sql.js is read from `sql-wasm.wasm`, next to its module, which the bundle of the application does
+  not keep: declare the file as a resource in `lakutata.resources` (its `from` is where npm installed `sql.js` in the
+  workspace), and give its path among the resources to `sqlJsConfig.locateFile` ([Packaging](Packaging.md), section 6).
+- A database server is reached over the network of the device; from an emulator, the computer is reached through
+  `adb reverse` (Android) or `hdc rport` (HarmonyOS).

package/doc/en/Entrypoint.md

@@ -60,6 +60,8 @@ The adapters:
 | `service` | `socketIOServiceEntrypoint()` | `lakutata/adapter/socket.io` | `socket.io` | [ServiceCalls](ServiceCalls.md) |
 | `service` | `jsonRPCServiceEntrypoint()` | `lakutata/adapter/jsonrpc` | `ws`, for WebSocket | [ServiceCalls](ServiceCalls.md) |
 | `service` | `electronIPCServiceEntrypoint()` | `lakutata/adapter/electron` | (Electron) | [ServiceCalls](ServiceCalls.md) |
+| `service` | `nwjsServiceEntrypoint()` | `lakutata/adapter/nwjs` | (NW.js) | [ServiceCalls](ServiceCalls.md) |
+| `service` | `reactNativeServiceEntrypoint()` | `lakutata/adapter/react-native` | | [ServiceCalls](ServiceCalls.md) |
 | `service` | `grpcServiceEntrypoint()` | `@lakutata/grpc/service` | `@lakutata/grpc` | [GRPC](GRPC.md) |
 | `service` | `natsServiceEntrypoint()` | `@lakutata/nats` | `@lakutata/nats` | [NATS](NATS.md) |
 | `schedule` | `scheduleEntrypoint()` | `lakutata/com/entrypoint` | | [Schedules](Schedules.md) |
@@ -181,8 +183,8 @@ actions of any other transport (`getActions('schedule')`). Each action is descri
 
 ## 6. Pushing events to the clients
 
-The service transports that keep their clients connected (Socket.IO, Electron, the event stream of the HTTP service,
-JSON-RPC over WebSocket or stdio, gRPC) can receive events from the application.
+The service transports that keep their clients connected (Socket.IO, Electron, NW.js, the event stream of the HTTP
+service, JSON-RPC over WebSocket or stdio, gRPC) can receive events from the application.
 `entrypoint.notify(clientId, event, ...args)` sends an event to the client whose id an action found in
 `this.context.clientId`, and returns whether that client received it. `entrypoint.broadcast(event, ...args)` sends it to
 every connected client, and returns their number. See [GRPC](GRPC.md) and [ServiceCalls](ServiceCalls.md).

package/doc/en/Exceptions.md

@@ -121,7 +121,7 @@ When an action fails, its transport reports the exception:
 | Transport | The client receives |
 |---|---|
 | HTTP | The status `statusCode` and `{errno, errMsg}` (see [HTTP](HTTP.md), section 6) |
-| Socket.IO, Electron, the HTTP service, NATS, gRPC | The whole error: all its own properties (see [ServiceCalls](ServiceCalls.md), section 3) |
+| Socket.IO, Electron, NW.js, the HTTP service, NATS, gRPC | The whole error: all its own properties (see [ServiceCalls](ServiceCalls.md), section 3) |
 | JSON-RPC | An error with the code `-32602` for an invalid input, `-32601` when no action matches, `-32001` while the application stops, `-32000` otherwise, and the whole error as its `data` |
 | The command line | `error: <message>` on the standard error, and the exit code 1 (see [CLI](CLI.md)) |
 | Schedules | No client: the exception is given to `onError`, or logged (see [Schedules](Schedules.md)) |

package/doc/en/FFI.md

@@ -433,7 +433,7 @@ Stopping a worker while asynchronous calls run in the threads of its libraries d
 
 ## 12. Runtimes
 
-Node.js `^22.13.0 || >=24.11.0`, the main process of Electron and Bun; not the renderers of Electron nor the browsers.
+Node.js `>=18.10.0`, the main process of Electron and Bun; not the renderers of Electron nor the browsers.
 
 The tests of the package, including those of the threads of a library, pass on macOS (arm64: Node.js 24, Bun 1.4,
 Electron 44), on Linux (arm64, glibc and musl: Node.js 24, Bun 1.4) and on Windows 11 (arm64, and x64 under emulation:

package/doc/en/GRPC.md

@@ -2,7 +2,7 @@
 
 The package `@lakutata/grpc` serves the service actions of an application over gRPC, and calls them from another
 application. Any language with a gRPC library can call them too. It is written in TypeScript over the HTTP/2 module of
-Node.js (`^22.13.0 || >=24.11.0`): no native addon and no generated code. `lakutata` does not include it, so install it
+Node.js (`>=18.10.0`): no native addon and no generated code. `lakutata` does not include it, so install it
 next to it:
 
 ```bash

package/doc/en/GettingStarted.md

@@ -5,7 +5,18 @@ and write an application by hand.
 
 ## 1. Requirements
 
-- Node.js `^22.13.0 || >=24.11.0`: 22.13 or a later 22.x, or 24.11 and later (not 23).
+- Node.js 18.10 or later (`>=18.10.0`). A few features need a newer Node.js:
+  - the Fastify adapter: Fastify 5 needs Node.js 18.19, 19.9, 20 or later (the Express adapter needs nothing more);
+  - the Kafka transport of `@lakutata/queue`: Node.js 22.22, 24.6 or later, as `@platformatic/kafka` needs;
+  - the executables of Node.js (`lakutata package exe`, the installers): made by a Node.js 20.12, 21.7 or later, or with
+    `--node-program` naming one;
+  - `await using` with the objects of the framework: Node.js 18.18, 20.4 or later.
+
+  On Node.js 18 and 19, an application uses commander 13, @inquirer/prompts 7 and better-sqlite3 11: their next major
+  versions need Node.js 20 or later.
+
+  The projects made by `lakutata create` declare Node.js `>=22.13.0`, which the tools of the web and desktop templates
+  need.
 - TypeScript, with its decorators (`experimentalDecorators`) and their metadata (`emitDecoratorMetadata`). The framework
   publishes the compiler options it needs as `lakutata/tsconfig.json`; the templates use TypeScript 6.
 - ES modules (`"type": "module"`), as in the templates; the package also ships CommonJS builds.
@@ -36,13 +47,16 @@ The `default` template is a small HTTP application. Other templates start from a
 | `web-react`, `web-vue` | An HTTP API serving a React or Vue single-page application (Vite) |
 | `web-next`, `web-nuxt` | An HTTP API serving a Next.js or Nuxt application from the same process |
 | `electron-react`, `electron-vue` | A desktop application: Electron, its main process serving a React or Vue renderer over IPC |
+| `nwjs-react`, `nwjs-vue` | A desktop application: NW.js, its background script serving a React or Vue user interface isolated in a webview |
+| `mobile-react` | A mobile application for Android, iOS and HarmonyOS: React Native, the Node.js inside it serving the user interface |
 
 ```bash
 npx @lakutata/cli create --name shop --template service --with i18n,installer
 ```
 
 `--with` adds optional features: `i18n` (messages in several languages) to every template, `installer` (installers
-and a system service) to `cli`, `service` and the `web-*` templates. In a terminal, the tool offers them when `--with`
+and a system service) to `cli`, `service` and the `web-*` templates, `win7` (NW.js 0.72, which runs on Windows 7) to
+the `nwjs-*` templates. In a terminal, the tool offers them when `--with`
 is not given. [ProjectStructure](ProjectStructure.md) describes the files of the templates, and
 [Command](Command.md) the options of `lakutata create`.
 

package/doc/en/HTTP.md

@@ -105,6 +105,7 @@ Both adapters serve the same actions, with the same results:
 |---|---|---|
 | Adapter | `expressHTTPEntrypoint()`, from `lakutata/adapter/express` | `fastifyHTTPEntrypoint()`, from `lakutata/adapter/fastify` |
 | Install | `express` (4 or 5) | `fastify` (5) |
+| Node.js | 18.10 and later | 18.19, 19.9, 20 and later (Fastify 5 needs `diagnostics_channel.tracingChannel`) |
 
 The options of `expressHTTPEntrypoint()`:
 

package/doc/en/I18n.md

@@ -174,7 +174,7 @@ The languages a request asks for are read from the sources below, in order, then
 | HTTP (Express, Fastify) | The query parameter `?lang=`, the cookie `lang`, then the `Accept-Language` header (by quality) |
 | Socket.IO | The query parameter `lang`, the cookie `lang` and `Accept-Language` of the connection's handshake |
 | HTTP service adapter, JSON-RPC (HTTP, WebSocket) | The query parameter `lang`, the cookie `lang` and `Accept-Language` of the HTTP request (for WebSocket, of the request opening the connection) |
-| Command line, Electron IPC, JSON-RPC over stdio | The variable named by `environmentVariable` (none by default), `LANGUAGE`, `LC_ALL`, `LC_MESSAGES`, `LANG`, then the language of the process |
+| Command line, Electron IPC, NW.js, React Native, JSON-RPC over stdio | The variable named by `environmentVariable` (none by default), `LANGUAGE`, `LC_ALL`, `LC_MESSAGES`, `LANG`, then the language of the process |
 | Schedules | None (the default language) |
 
 A query or cookie value that is not a language tag is skipped.

package/doc/en/Installers.md

@@ -21,7 +21,8 @@ npx lakutata package installer --target pkg     # only some of them
 
 An installer holds the executable of the directory layout (`lakutata package exe --layout directory`): the program,
 its native addons (`native/`) and its resources (`resources/`). The program is made with Node.js, or with Bun when
-`lakutata.installer.runtime` is `"bun"`.
+`lakutata.installer.runtime` is `"bun"`. On a Node.js older than 20.12, give a newer one with `--node-program`, as for
+the executables.
 
 | Platform | Installers (default) | Their files | Made with |
 |---|---|---|---|
@@ -68,19 +69,19 @@ The installers are configured by `lakutata.installer` in the `package.json` of t
 | `description`, `homepage`, `license` | Those of the `package.json` | The information of the packages |
 | `maintainer` | The `author` of the `package.json` | Its maintainer (`Name <email>`); without one, the tool warns |
 | `vendor` | None | Its vendor; on Windows, the publisher is the vendor, else the maintainer |
-| `runtime` | `node` | `node` or `bun` for the executable; `electron` for an Electron application (section 8) |
+| `runtime` | `node` | `node` or `bun` for the executable; `electron` for an Electron application (section 8), `nwjs` for an NW.js application (section 9) |
 | `addToPath` | `true` | Put the program in the PATH: `/usr/bin/<program>` on Linux, `/usr/local/bin/<program>` on macOS, the PATH of the machine on Windows |
 | `service` | None | `true`, or the options of the service (section 4) |
 | `linux.targets` | `deb`, `rpm`, `tar.gz`; on Alpine `apk`, `tar.gz` | The Linux installers (`deb`, `rpm`, `archlinux`, `tar.gz`; `apk`, `tar.gz` on Alpine) |
 | `linux.depends`, `linux.recommends` | None | The system packages it needs and recommends (the C++ runtime library is always added) |
 | `linux.section`, `linux.priority` | None | Its section and its priority (deb) |
-| `mac.targets` | `pkg`, `tar.gz` | The macOS installers |
+| `mac.targets` | `pkg`, `tar.gz` | The macOS installers (`dmg` too, for an NW.js application) |
 | `win.targets` | `nsis`, `msi`, `zip` | The Windows installers |
 | `linux.scripts`, `mac.scripts`, `win.scripts`… | None | The scripts of the installers (section 5) |
 | `electron` | None | The configuration of electron-builder (section 8) |
 
 `lakutata.icon` (beside `lakutata.installer`) is a square PNG image of 256 pixels or more: the icon of the Windows
-executable and installers, and of the Electron applications.
+executable and installers, and of the Electron and NW.js applications.
 
 The configuration is checked before anything is built, the options of the installers that are not made included, and an
 error names the field:
@@ -202,8 +203,9 @@ fi
 
 ## 6. Signing
 
-- **macOS**: the `pkg` installers are not signed, and the program they install is signed ad hoc only. The Developer ID
-  signature and the notarization, which distribution outside the machines of the organization needs, are not made yet.
+- **macOS**: the `pkg` installers and the `dmg` images are not signed, and the program or the application they install
+  is signed ad hoc only. The Developer ID signature and the notarization, which distribution outside the machines of the
+  organization needs, are not made yet.
 - **Windows**: the NSIS and MSI installers are not signed: sign them with signtool before distributing them. The program
   made with Node.js keeps the signature of `node.exe`, which no longer matches, and the tool warns of it.
 - **Linux**: the packages are not signed.
@@ -278,3 +280,29 @@ and `electron-vue` templates are configured this way.
   ([NativeAddons](NativeAddons.md), section 4).
 - On Linux arm64, the deb and rpm packages need the fpm of the system (`gem install fpm`, `USE_SYSTEM_FPM=true`), as the
   `Dockerfile.installer` of the Electron templates installs it.
+
+## 9. NW.js applications
+
+With `"runtime": "nwjs"`, the installers hold an NW.js application made by the builder: the normal flavor of the NW.js
+of the application (its `lakutata.nwjs`, given by `lakutata nwjs use`), downloaded once into the cache of lakutata and
+checked against the checksums of its release, with the application in it: its bundle for the Node.js of that NW.js, its
+native addons, its resources (`lakutata.resources`, read through `resourcesPath()`) and the manifest of NW.js. The
+`nwjs-react` and `nwjs-vue` templates are configured this way.
+
+- **The runtime** is named after the application: on Windows, `<name>.exe`, whose icon and version information are
+  those of the application; on Linux, `<name>`; on macOS, `<productName>.app`, whose `Info.plist` gives its name, its
+  identifier (`appId`), its version and its icon, and which is signed again ad hoc.
+- **The installers** are those of a desktop application: `dmg` on macOS, `nsis` on Windows and `deb` on Linux by
+  default (also `pkg` and `tar.gz` on macOS, `msi` and `zip` on Windows, `rpm` and `tar.gz` on Linux). The Windows
+  installers add the application to the start menu and to the desktop; the `dmg` disk image holds it beside a link to
+  /Applications, where its user drags it, and the `pkg` package installs it there (an Intel application, on the Macs
+  of Apple silicon too); the Linux packages add its desktop entry and its icons, and depend on the libraries of
+  Chromium.
+- **The architecture** is the one of the machine, or the one of `--arch` (`x64`, `ia32`, `arm64`): `ia32` makes the
+  installers of 32-bit Windows, which install the application among the programs of 32 bits. A release of NW.js
+  without a build for the Macs of Apple silicon (0.72) is packaged for Intel.
+- **An NW.js application is not a service**, and is not put in the PATH (`addToPath` is `false` by default).
+- **The scripts** run as for the other applications, but a macOS application is removed by deleting it: no removal
+  script runs there.
+- **Native addons** are made to load in NW.js: built again for its architecture, or with its headers when they use the
+  V8 API, and, on Windows, given the Node.js of NW.js ([NativeAddons](NativeAddons.md), section 4).

package/doc/en/Math.md

@@ -348,7 +348,7 @@ $ curl -X POST localhost:8080/solve -H 'Content-Type: application/json' -d '{"eq
 - The bundles, the executables and the installers made by `lakutata package` carry the compiled addon
   (`build/Release/math.node`). Build them on each target platform, after installing the package there; the rules of
   the native addons apply (see [Packaging](Packaging.md) and [NativeAddons](NativeAddons.md)).
-- The package runs in Node.js `^22.13.0 || >=24.11.0`, in Bun and in the main process of Electron, which load the
+- The package runs in Node.js `>=18.10.0`, in Bun and in the main process of Electron, which load the
   addon compiled for Node.js; not in the renderers of Electron nor in the browsers. In Bun, terminating a worker thread
   while operations of the addon still run in it ends the whole process with a fatal error of Node-API (a bug of Bun
   1.4).

package/doc/en/Migrations.md

@@ -143,8 +143,8 @@ export class Migrations1792161460658 implements MigrationInterface {
   compiled files.
 - Read the migration before running it: a renamed property becomes a column dropped and a column added, with the data
   of the old one lost. Edit the SQL when needed.
-- When nothing changed, the command writes nothing and exits with the code 1 (`No changes in database schema were
-  found`).
+- When nothing changed, the command writes nothing, says so (`No changes in database schema were found`) and exits with
+  the code 0.
 - With several databases, each database whose tables differ gets its own file. Give each database a `migrations` option
   that lists only its own files (`'build/migrations/*-db.js'`), or the databases would run each other's migrations.
 

package/doc/en/NativeAddons.md

@@ -66,14 +66,13 @@ And `src/index.ts`, the same for all three:
 ```typescript
 import {createRequire} from 'node:module'
 import path from 'node:path'
-import {fileURLToPath} from 'node:url'
 
 type Binding = {
     greet(name: string): string
 }
 
 /** The addon built into build/Release, loaded from the directory of the package */
-const binding: Binding = createRequire(import.meta.url)('node-gyp-build')(path.resolve(path.dirname(fileURLToPath(import.meta.url)), '..'))
+const binding: Binding = createRequire(__filename)('node-gyp-build')(path.resolve(__dirname, '..'))
 
 export function greet(name: string): string {
     return binding.greet(name)
@@ -96,6 +95,8 @@ export function greet(name: string): string {
   for the architecture of the machine (`rustup target add` adds the other ones).
 - **Node-API**: the addons are built for Node-API version 8, which every supported version of Node.js and of Electron
   provides, so they are not rebuilt for each of them.
+- **CommonJS**: the package is CommonJS (`"type": "commonjs"`). The bundles of `lakutata package` are CommonJS and
+  load it with `require`, which can load an ES module only on Node.js 20.19, 22.12 or later.
 - The package is `"private": true`, like every package that `lakutata add` creates: an addon is usually shipped with
   its application rather than published.
 
@@ -214,5 +215,14 @@ The application depends on the addon package, and imports it as any package (`im
 - **Electron**: the addons are copied as they are installed. The addons that `lakutata add` creates run in Electron
   without being rebuilt, as do all the addons built on Node-API; an addon built on the V8 API of Node.js must be
   installed in its build for Electron before packing (`electron-rebuild`).
+- **NW.js**: the addons are made to load in NW.js when the application runs in it (`lakutata nwjs run`, and once
+  packaged). The ones built for another architecture than the one of the runtime are built again from their sources,
+  with the headers of the Node.js of NW.js; so are the ones built on the V8 API of Node.js, with the headers of NW.js
+  (NW.js 0.111.3 or later: the earlier releases, such as 0.72 for Windows 7, run the addons of Node-API only). On
+  Windows, the addons load the Node.js of NW.js (`node.dll`). The addons of the project are left as they are, for its
+  tests with Node.js.
+- **Mobile applications** (React Native): `lakutata mobile stage` builds the addons from their sources for Android, iOS
+  and HarmonyOS, against the libnode the application embeds (see the `lakutata mobile` commands in the README of
+  `@lakutata/cli`).
 - **Bun**: Bun loads the addons of Node-API; an executable of Bun warns of the addons built on the V8 API of Node.js.
 - **Alpine (musl)**: the executables of Node.js do not load native addons there: make them with Bun.

package/doc/en/Overview.md

@@ -1,10 +1,11 @@
 # Lakutata Overview
 
 **Lakutata** is an IoC application framework for Node.js and TypeScript. It gives web services, CLI tools, desktop
-(Electron) applications and embedded devices one programming model: an application is a tree of objects (components,
-providers, controllers) that a container creates. DTOs validate their options and inputs, and transports expose
-the controllers: HTTP (Express, Fastify), CLI (Commander), service RPC (HTTP, Socket.IO, JSON-RPC 2.0, gRPC, NATS,
-Electron IPC), schedules and message queues. One controller method can serve all of them at once.
+(Electron, NW.js) applications and embedded devices one programming model: an application is a tree of objects
+(components, providers, controllers) that a container creates. DTOs validate their options and inputs, and transports
+expose the controllers: HTTP (Express, Fastify), CLI (Commander), service RPC (HTTP, Socket.IO, JSON-RPC 2.0, gRPC,
+NATS, Electron IPC, NW.js, React Native), schedules and message queues. One controller method can serve all of them at
+once.
 
 The package `lakutata` re-exports the `@lakutata/*` packages under its subpaths (see the table below) and presets two
 components in every application: `log` (the `Logger`, which writes pino-compatible JSON lines) and `entrypoint` (the
@@ -30,7 +31,7 @@ tool, a web and a desktop application, calls between services, background jobs,
 | `lakutata/decorator/ctrl` | `@HTTPAction`, `@GET`…`@OPTIONS`, `@CLIAction`, `@ServiceAction`, `@Schedule`, `@Prefix`, `@UseMiddlewares` |
 | `lakutata/adapter/express`, `lakutata/adapter/fastify` | The HTTP transports |
 | `lakutata/adapter/commander` | The CLI transport |
-| `lakutata/adapter/socket.io`, `lakutata/adapter/jsonrpc`, `lakutata/adapter/electron` | The service transports |
+| `lakutata/adapter/socket.io`, `lakutata/adapter/jsonrpc`, `lakutata/adapter/electron`, `lakutata/adapter/nwjs`, `lakutata/adapter/react-native` | The service transports |
 | `lakutata/com/logger` | The `Logger` component, preset as `log` (pino-compatible JSON lines) |
 | `lakutata/orm`, `lakutata/decorator/orm` | TypeORM and its decorators |
 | `lakutata/com/database`, `lakutata/provider/database` | The `Database` component and provider |
@@ -46,11 +47,12 @@ tool, a web and a desktop application, calls between services, background jobs,
 
 Not part of this package: `@lakutata/cli` (the `lakutata` command for creating projects, running migrations and packing
 applications, see [Command](Command.md)), `@lakutata/grpc` (a gRPC client, server and service transport),
-`@lakutata/nats` (a NATS component and service transport), `@lakutata/dbus` (D-Bus), `@lakutata/mcp` (the Model
-Context Protocol), `@lakutata/webrtc` (WebRTC: the signaling, a TURN server, a media server, peer connections),
-`@lakutata/ffi` (the C functions of native libraries), `@lakutata/math` (symbolic and numeric mathematics, as functions
-that need no lakutata application) and `@lakutata/netif` (servers and UDP sockets listening on a network interface
-whatever its addresses, the interfaces of the machine and their changes).
+`@lakutata/nats` (a NATS component and service transport), `@lakutata/dbus` (D-Bus), `@lakutata/mcp` (the Model Context
+Protocol), `@lakutata/webrtc` (WebRTC: the signaling, a TURN server, a media server, peer connections), `@lakutata/ffi`
+(the C functions of native libraries), `@lakutata/math` (symbolic and numeric mathematics, as functions that need no
+lakutata application), `@lakutata/barcode` (barcodes and QR codes, generated and read in a native addon) and
+`@lakutata/netif` (servers and UDP sockets listening on a network interface whatever its addresses, the interfaces of
+the machine and their changes).
 
 ## The guides
 
@@ -74,7 +76,7 @@ whatever its addresses, the interfaces of the machine and their changes).
 | [Middlewares](Middlewares.md) | The middlewares and the access control of the actions |
 | [HTTP](HTTP.md) | The HTTP adapters: routes, input, responses, errors, the features of Express and Fastify |
 | [CLI](CLI.md) | Command line tools: commands, options, prompts, output and exit codes |
-| [ServiceCalls](ServiceCalls.md) | The service actions over HTTP, Socket.IO, JSON-RPC 2.0 and Electron: patterns, responses, clients and their events |
+| [ServiceCalls](ServiceCalls.md) | The service actions over HTTP, Socket.IO, JSON-RPC 2.0, Electron and NW.js: patterns, responses, clients and their events |
 | [GRPC](GRPC.md) | The service actions over gRPC (`@lakutata/grpc`), and calling them from other applications and languages |
 | [NATS](NATS.md) | The NATS component, the service actions over NATS (`@lakutata/nats`), the service proxies and their events |
 | [Schedules](Schedules.md) | Scheduled jobs: intervals, cron expressions, jobs run by one instance |
@@ -95,6 +97,7 @@ whatever its addresses, the interfaces of the machine and their changes).
 | [MCP](MCP.md) | The tools, resources and prompts of the Model Context Protocol (`@lakutata/mcp`), over stdio and HTTP |
 | [WebRTC](WebRTC.md) | Peer-to-peer connections and a media server (`@lakutata/webrtc`): the signaling, the TURN server, browsers and applications, the actions of an application called through data channels, WHIP and WHEP |
 | [FFI](FFI.md) | The C functions of native libraries (`@lakutata/ffi`): declarations copied from headers, structs, callbacks, memory, packaging |
+| [Barcode](Barcode.md) | Barcodes and QR codes (`@lakutata/barcode`): generating them as PNG, SVG or pixels, sizes for print, EAN, UPC and GS1, reading them from images |
 | [Math](Math.md) | Mathematics (`@lakutata/math`): formulas and exact results, equations, decimals of any precision, matrices, statistics, numeric solutions, units |
 | [Netif](Netif.md) | Network interfaces (`@lakutata/netif`): a server listening on an interface whatever its addresses, the connections of the other interfaces refused, the interfaces and their changes, UDP on one interface |
 | [Command](Command.md) | The `lakutata` command: creating projects, migrations, translations, environment variables |

package/doc/en/Packaging.md

@@ -10,6 +10,10 @@ A compiled application can be shipped without its `node_modules`, in three forms
 `lakutata package bundle`, `package exe` and `package installer` make them with `@lakutata/builder`, which the project
 installs (`npm install --save-dev @lakutata/builder`; the templates that pack their application already have it).
 
+A mobile application of the `mobile-react` template is shipped another way: `lakutata mobile stage` bundles its
+application for the Node.js the mobile application embeds, and its native projects make the release builds for the
+stores (see the section The packaging of the README the template gives the project).
+
 ## 1. What is packed
 
 - **The compiled application**: the output of `tsc` (which emits the metadata of the decorators), not the TypeScript
@@ -49,6 +53,7 @@ directory, once moved with them.
 | `--outfile <file>` | The bundle, `dist/<name>.cjs` by default |
 | `--no-minify` | Do not minify the bundle (the names of the classes are kept either way) |
 | `--external <modules...>` | Modules left out of the bundle, loaded at run time from a `node_modules` next to it |
+| `--node <version>` | The version of Node.js running the bundle (`18.10` for NW.js 0.70): the bundle is written in the syntax that version reads; the one running the tool by default |
 
 ## 3. Native addons
 
@@ -124,11 +129,12 @@ architecture for Linux (`docker run --platform linux/arm64`); the README of the
 
 | Option | Meaning |
 |---|---|
-| `--runtime node` (default) | The bundle is embedded in a copy of the Node.js running the tool (a single executable application of Node.js): about 110 MB on macOS arm64 |
+| `--runtime node` (default) | The bundle is embedded in a copy of the Node.js running the tool, or of `--node-program` (a single executable application of Node.js): about 110 MB on macOS arm64 |
 | `--runtime bun` | The bundle is compiled by Bun (the `bun` package of the project, else the `bun` of the system): about 70 MB on macOS arm64, and it starts faster; the runtime is then Bun |
 | `--layout file` (default) | One file: the native addons, the files read by path and the resources are embedded, and extracted when it starts |
 | `--layout directory` | `dist/<name>/` holds the executable, `native/` and `resources/`, loaded from there without extraction (the installers use it) |
 | `--outdir <directory>` | Where the executable is written, `dist` by default |
+| `--node-program <path>` | The node embedded instead of the one running the tool: a Node.js 20.12, 21.7 or later (`$(nvm which 22)`), so that an older Node.js can run the tool; the bundle follows its syntax |
 | `--entry`, `--no-minify`, `--external` | As for a bundle |
 
 - **Extraction**: an executable of the file layout extracts what it embeds at its first run, into its cache directory,
@@ -171,6 +177,7 @@ of the project (it may be outside the package, such as `../ui/dist`), `to` its p
 | An executable, file layout | `true` | The directory the resources were extracted to |
 | An executable, directory layout, or an installed application | `true` | `resources` next to the executable |
 | A packaged Electron application | `true` | `main.resources` in the resources of Electron |
+| An NW.js application (run by `lakutata nwjs run`, or packaged) | `true` | `resources` in the directory of the application |
 
 `resourcesPath()` returns the path even when the application declares no resources, so the directory may not exist.
 The application chooses where to read its files from:

package/doc/en/ProjectStructure.md

@@ -53,8 +53,8 @@ templates other than `cli` do.
 ## 2. The workspace templates
 
 The other templates are npm workspaces: the application is the package `packages/app`, and the templates with an
-interface or with installers add `packages/ui` (the web pages, or the renderer of Electron) and `packages/resources`
-(the icon). The `service` template:
+interface or with installers add `packages/ui` (the web pages, the renderer of Electron, or the user interface of
+NW.js) and `packages/resources` (the icon). The `service` template:
 
 ```
 shop/
@@ -93,6 +93,20 @@ The other templates add to this layout:
   it into `dist/` ([Packaging](Packaging.md)).
 - `electron-react` and `electron-vue`: the main process of Electron in `packages/app` (its window and its service
   actions over IPC), the renderer in `packages/ui`, and the scripts that make the installers.
+- `nwjs-react` and `nwjs-vue`: the background script of NW.js in `packages/app` (its window, whose host page in
+  `packages/app/host` holds the user interface in a webview, and its service actions), the user interface in
+  `packages/ui`, the version of NW.js in `packages/app/nwjs.json` (written by `npm run nwjs:use -- <version>`), and the
+  scripts that make the installers.
+- `mobile-react`: the application in `packages/app`, which runs in a Node.js embedded in the mobile application and
+  serves its actions to the user interface of React Native; the user interface in `packages/ui` (`src/App.tsx`), the
+  same on the three systems; `packages/ipc`, which connects the user interface to the Node.js side: the native module
+  embedding Node.js (`native`) and the `ipc` the user interface imports (Electron and NW.js have such a channel of their
+  own, React Native has none, so the template brings it as a package); at the root, the application of React Native
+  itself: its entry (`index.js`, which registers the component of `packages/ui`), `app.json`, the configurations of
+  Metro and Babel, and the native projects (`android`, `ios`, `harmony`), which carry the id of the application
+  (`lakutata create --bundle-id`); and the scripts that download the libnode, run the application on an emulator, a
+  device or a simulator, and deploy its Node.js side (`npm run node:android`, `npm run android`, `npm run
+  deploy:android`, and the same for `ios` and `harmony`).
 
 The packed forms are written to `dist/` at the root of the workspace; `.gitignore` leaves out `build`, `dist` and the
 outputs of the interfaces.
@@ -105,8 +119,9 @@ outputs of the interfaces.
 |---|---|---|
 | `i18n` | all | The messages of the languages in `src/locales` (`en`, `zh-CN`), the `i18n` component, the language middleware, and the scripts `i18n:check` and `i18n:types` ([I18n](I18n.md)) |
 | `installer` | `cli`, `service`, `web-*` | The `lakutata.installer` of the application, the scripts that make the installers (on the machine, and for Linux in Docker), and for the services a system service ([Installers](Installers.md)) |
+| `win7` | `nwjs-*` | NW.js 0.72.0 instead of the release the template was published with: the last release running on Windows 7, 8 and 8.1, and the script `package:ia32` that makes the installers of 32-bit Windows |
 
-The Electron templates make installers without this feature.
+The Electron and NW.js templates make installers without the `installer` feature.
 
 ## 4. Templates of your own