@lakutata/cli 3.1.4 → 3.1.6

package/README.md

@@ -22,11 +22,12 @@ both the features and the confirmation).
 |---|---|
 | `--name <name>` | the name of the application (required) |
 | `--id <id>` | the ID of the application (a package name), by default its name in lower case |
+| `--bundle-id <id>` | the id of the application on the mobile systems (reverse domain name: `com.acme.shop`), for the mobile templates: `com.example.<name>` by default, which the stores refuse |
 | `--template <template>` | the template (`default` when it is not given): an official template (listed by `lakutata templates`), `npm:<package>[@<version>]`, `github:<owner>/<repo>[#<ref>]` or a directory |
 | `--path <directory>` | the directory in which the project directory is created, by default the current one |
 | `--init` | create the project in the `--path` directory itself, which must exist and may hold files: the files it already has are kept (a warning lists those that the template also has, to merge by hand), and only the files the tool writes are filled with the information of the project |
 | `--description`, `--author`, `--license` | information about the application |
-| `--with <features>` | the optional features of the template to enable, separated by commas (listed by `lakutata templates`): `i18n`, `installer`. In a terminal, without `--with` or `--yes`, you choose them from a list |
+| `--with <features>` | the optional features of the template to enable, separated by commas (listed by `lakutata templates`): `i18n`, `installer`, `win7`. In a terminal, without `--with` or `--yes`, you choose them from a list |
 | `--package-manager <npm\|pnpm\|yarn\|none>` | the package manager that installs the dependencies (`none` installs nothing): npm by default, or pnpm or yarn when one of them started the tool |
 | `--no-git` | do not initialize a git repository |
 | `--yes` | create the project without asking for the features or for a confirmation |
@@ -38,11 +39,13 @@ lakutata create --name my-service --template service --with i18n --yes
 
 Every official template has the `i18n` feature: the messages of the application in several languages
 (`lakutata/com/i18n`), in `src/locales` (`en.json`, `zh-CN.json`) and bundled with the code. Each request is answered in
-its own language, including its validation errors (command line tools and Electron applications use the language of the
+its own language, including its validation errors (command line tools and desktop applications use the language of the
 environment). The feature also adds the `i18n:check` and `i18n:types` scripts. The `cli`, `service` and `web-*`
 templates also have the `installer` feature: the `lakutata.installer` configuration of the application and the scripts
 that make its installers (on the machine, and for Linux in Docker), and, in the `service` and `web-*` templates, a
-system service.
+system service. The `nwjs-*` templates have the `win7` feature: NW.js 0.72.0, the last release running on Windows 7, 8
+and 8.1, instead of the release the template was published with, and the script that makes the installers of 32-bit
+Windows.
 
 ### `lakutata templates`
 
@@ -408,12 +411,12 @@ platforms (the Linux ones can be made in a container). They are configured by th
 | `productName` | the name shown to users (in the installers, and in the list of programs on Windows), by default the `productName` of the `package.json`, else the name |
 | `description`, `maintainer`, `homepage`, `license` | by default those of the `package.json` (the maintainer is its author) |
 | `vendor` | its vendor, none by default (on Windows, the publisher is the vendor, else the maintainer) |
-| `runtime` | the runtime of the executable: `node` (the default) or `bun`; `electron` for an Electron application (below) |
-| `addToPath` | put the program in the PATH (`/usr/bin/<program>`, `/usr/local/bin/<program>` on macOS; on Windows, the PATH of the machine), `true` by default |
+| `runtime` | the runtime of the executable: `node` (the default) or `bun`; `electron` for an Electron application, `nwjs` for an NW.js application (below) |
+| `addToPath` | put the program in the PATH (`/usr/bin/<program>`, `/usr/local/bin/<program>` on macOS; on Windows, the PATH of the machine), `true` by default (`false` for an NW.js application) |
 | `service` | `true` or the options of the service (below), none by default |
 | `linux.targets` | `deb`, `rpm`, `archlinux`, `tar.gz` on glibc systems (`deb`, `rpm`, `tar.gz` by default); `apk`, `tar.gz` on Alpine (musl) |
 | `linux.depends`, `linux.recommends`, `linux.section`, `linux.priority` | the system packages it needs and recommends, its section and its priority (deb) |
-| `mac.targets` | `pkg`, `tar.gz` (both by default) |
+| `mac.targets` | `pkg`, `tar.gz` (both by default); `dmg` for an NW.js application |
 | `win.targets` | `nsis`, `msi`, `zip` (all by default) |
 | `electron` | the electron-builder configuration of an Electron application, merged over the one made from these options |
 
@@ -527,11 +530,140 @@ one electron-builder downloads is built for x64. On Windows arm64, the NSIS inst
 the BCJ filter (`ELECTRON_BUILDER_7Z_FILTER`), because they cannot extract files compressed with the ARM64 filter,
 which 7-Zip would choose.
 
+The installers of an NW.js application (`"runtime": "nwjs"`) hold the normal flavor of its NW.js (`lakutata nwjs use`,
+below), named after the application, with the application in it: its bundle for the Node.js of that NW.js, its native
+addons made to load in it, its resources and the manifest of NW.js. On Windows, the executable is `<name>.exe`, with
+the icon and the version information of the application; on macOS, the bundle is `<productName>.app`, whose
+`Info.plist` gives its name, its `appId`, its version and its icon (signed again ad hoc). Its installers are those of a
+desktop application, by default `deb` on Linux, `dmg` on macOS and `nsis` on Windows: the Windows installers (`nsis`,
+`msi`) add it to the start menu and to the desktop, the `dmg` disk image holds it beside a link to /Applications and
+the `pkg` package installs it there, and the Linux packages (`deb`, `rpm`) add its desktop entry and its icons and
+depend on the libraries of Chromium. `--arch` makes them for another architecture than the one of the machine (`ia32`:
+32-bit Windows). An NW.js application is not a service; its scripts run as for the other applications (on macOS, it is
+removed by deleting it, without a removal script).
+
 | Command option | |
 |---|---|
 | `--target <targets...>` | the installers to make, by default those of the configuration |
 | `--outdir <directory>` | the directory of the installers, `dist/installer` by default |
 | `--entry`, `--no-minify`, `--external` | as for `lakutata package exe` |
+| `--arch <arch>` | the architecture of an NW.js application (`x64`, `ia32`, `arm64`), the one of the machine by default |
+
+## NW.js
+
+An NW.js application (the `nwjs-react` and `nwjs-vue` templates) runs in the version of NW.js of its `package.json`,
+`"lakutata": {"nwjs": {"version": "0.119.2"}}`. The runtimes of NW.js are downloaded once into the cache of lakutata
+(from `https://dl.nwjs.io`, or the mirror of `LAKUTATA_NWJS_MIRROR`) and checked against the checksums of their release.
+lakutata runs on the releases whose Node.js is 18.10 or later.
+
+### `lakutata nwjs versions`
+
+List the releases of NW.js lakutata runs on, newest first: their date, their Node.js, their Chromium and their builds,
+the latest and the last one running on Windows 7 (`win7`, 0.72.0) marked. It lists the ten latest and the one of
+Windows 7, every release with `--all`. The list of the releases (`https://nwjs.io/versions.json`, or the one of
+`LAKUTATA_NWJS_VERSIONS`) is cached for a day.
+
+### `lakutata nwjs use <version>`
+
+Give the application of the current directory its version of NW.js: a version (`0.119.2`), `latest` or `win7`, written
+as a version into the `lakutata.nwjs` of its `package.json`. It writes `nwjs.json` too, the version with its Node.js and
+its Chromium, which the templates' build of the user interface reads to target that Chromium, and tells the systems the
+release runs on. `--download` downloads its sdk flavor for the machine at once.
+
+### `lakutata nwjs run [args...]`
+
+Run the compiled application of the current directory in NW.js: it is bundled into `.nwjs/app` for the Node.js of its
+NW.js, with its resources and its native addons made to load in it, then run with the arguments given after `--`
+(`lakutata nwjs run -- --ui=http://localhost:5173`). The command ends with NW.js, and stops it when it is stopped.
+
+| Option | |
+|---|---|
+| `--release <version>` | the release of NW.js run (a version, `latest`, `win7`), the one of `lakutata.nwjs` by default |
+| `--flavor <sdk\|normal>` | `sdk` (the default: with the DevTools) or `normal` (the one the installers hold) |
+
+## Mobile applications
+
+A mobile application of React Native laid out as the `mobile-react` template (Android, iOS, HarmonyOS) runs the
+application of `packages/app` in a libnode, the library of Node.js that its native module (`packages/ipc/native`)
+embeds; its native projects are at the root of the project, its user interface in `packages/ui`. These commands, run in
+any directory of the project, download that libnode, make the Node.js project of the application, run the application,
+and deploy the project during the development.
+
+### `lakutata mobile node <platform>`
+
+Download the libnode of a system (`android`, `ios` or `harmony`) from the releases of
+[lakutata/libnode](https://github.com/lakutata/libnode) and put it into `packages/ipc/native/node/out/<platform>`, which
+the native projects build against; for HarmonyOS, `libnode.so` is put into the libraries of the HAP too
+(`harmony/entry/libs/arm64-v8a`). Its archives (`libnode_<platform>_<arch>.tar.gz`, one per architecture) are checked
+with the `SHA256SUMS` of the release and kept in the cache of lakutata (`~/.cache/lakutata/mobile`): they are downloaded
+once. `lakutata mobile stage` downloads the libnode of a system when the project has none yet.
+
+- `LAKUTATA_LIBNODE_MIRROR` gives a mirror of the releases, its files laid out as on GitHub
+  (`<mirror>/v<version>/libnode_android_arm64.tar.gz`, `<mirror>/v<version>/SHA256SUMS`).
+- `LAKUTATA_MOBILE_NODE_DIR` gives a libnode of your own instead, built with the repository of lakutata/libnode: a
+  directory per system (`android`, `ios`, `harmony`), as its builds export them.
+
+| Option | |
+|---|---|
+| `--abis <list>` | the architectures of Android, separated by commas (`arm64-v8a,armeabi-v7a,x86_64`), `arm64-v8a,x86_64` by default |
+
+### `lakutata mobile stage <platform>`
+
+Make the Node.js project of the application where the native project of the system takes it:
+`android/app/src/main/assets/nodejs` (copied into the files of the application at its first launch), `ios/nodejs` (put
+into the bundle of the application by its build) or `harmony/entry/src/main/resources/resfile/nodejs` (run from the
+resources of the HAP). The project holds the bundle of the application for the version of Node.js of the libnode, its
+resources, its `package.json` and its entry, which puts away `fetch()` where there is no WebAssembly (HarmonyOS).
+
+The native addons of the dependencies are built for the system from the sources of their packages (`binding.gyp`),
+against the headers and the libraries of the libnode. For Android, each architecture of the libnode gets a native tree
+of its own, built by node-gyp with the NDK (the latest one of the Android SDK, or `ANDROID_NDK_HOME`); a package that
+ships prebuilt addons of Android (`prebuilds/android-<arch>`) keeps them. For iOS, on macOS, each addon becomes a
+framework for the devices and one for the simulators, built with Xcode into `ios/NodeAddons`, which the build of the
+application embeds. An addon is built with the settings its package gives to macOS (`OS=="mac"` in its `binding.gyp` and
+in the gyp files of node-addon-api), while the SDK, the architecture and the deployment target are those of iOS. For
+HarmonyOS, each addon becomes a library of the HAP (`libaddon-<package>-<file>.so` in `harmony/entry/libs/arm64-v8a`),
+built with the native SDK of DevEco Studio (or `OHOS_NDK_HOME`). The builds are kept in the cache of lakutata.
+
+| Option | |
+|---|---|
+| `--abis <list>` | the architectures of Android the addons are built for, those of the libnode by default |
+| `--no-minify` | keep the bundle readable |
+
+### `lakutata mobile run <platform>`
+
+Build the debug application of the system and run it, its user interface loaded from Metro (`npm start`). The Node.js
+project of the application installed replaces a copy deployed before.
+
+- Android: on the emulator or the device running (or given), built by Gradle for its architecture, installed, Metro made
+  reachable from it (`adb reverse`), and started. adb is found in the Android SDK (`ANDROID_HOME`), else in the `PATH`.
+- iOS: on a simulator (the one given, else the one running, else the newest iPhone, booted when needed), its pods
+  installed first when the `Podfile` changed, built with `xcodebuild`, installed and started with `xcrun simctl`, and
+  shown in Simulator or in Device Hub.
+- HarmonyOS: on the emulator or the device connected (or given), its user interface bundled into the HAP
+  (`react-native bundle-harmony`), the libraries of React Native ported to HarmonyOS linked (`react-native
+  link-harmony`, which adds their packages to `harmony/oh-package.json5`), its ohpm dependencies installed
+  (`ohpm install --all`), built by the hvigor of DevEco Studio (`DEVECO_STUDIO_HOME`, its SDK `DEVECO_SDK_HOME`), installed with hdc, Metro made reachable from it
+  (`hdc rport`), and started.
+
+| Option | |
+|---|---|
+| `--device <id>` | the emulator or the device of Android (its serial, `adb devices`) or of HarmonyOS (`hdc list targets`), the simulator of iOS (its UDID or its name, `xcrun simctl list devices`) |
+
+### `lakutata mobile deploy <platform>`
+
+Make the project, put it into the debug application installed on the device, and start the application again: the
+Node.js side changes without installing the application again. On Android it writes into the files of the application
+(`adb shell run-as`), marked so that the application keeps it until it is installed again; on iOS into the application
+in the simulator, with the frameworks of the addons; on HarmonyOS into the files of the application (`hdc file send`),
+which the native module runs instead of the project of the resources. The native addons are built for the device only
+(its architecture of Android, the simulators of iOS); those of HarmonyOS are libraries of the HAP, which
+`lakutata mobile run harmony` installs.
+
+| Option | |
+|---|---|
+| `--device <id>` | as for `lakutata mobile run` |
+| `--watch` | watch the files of the application (not its dependencies or its compiled files): when they change, run its `build` script and deploy it again, until Ctrl+C |
 
 ## Migrations
 
@@ -563,8 +695,8 @@ its entrypoints. `create` only writes a file.
 
 The migrations are compiled with the application and listed in the options of their database (`migrations: [...]`;
 they run when it connects with `migrationsRun: true`). The commands fail (exit code 1) when the application has no
-database (except `generate`, which then generates nothing), when the given database is not one of the application,
-and when a migration fails.
+database (except `generate`, which then generates nothing and exits with 0, as it does when the schema has no changes),
+when the given database is not one of the application, and when a migration fails.
 
 ## Languages
 
@@ -604,6 +736,8 @@ matches. The names of the commands and options, and the other results and errors
 | `LAKUTATA_NPM_REGISTRY` | the npm registry of the templates (by default `npm_config_registry`, else `https://registry.npmjs.org`) |
 | `LAKUTATA_GITHUB_DOWNLOAD` | a GitHub mirror for the `github:` templates (`https://github.com` by default) |
 | `LAKUTATA_CACHE_DIR` | the cache directory (by default `$XDG_CACHE_HOME/lakutata`, else `~/.cache/lakutata`) |
+| `LAKUTATA_NWJS_MIRROR` | where the runtimes of NW.js are downloaded from (`https://dl.nwjs.io` by default) |
+| `LAKUTATA_NWJS_VERSIONS` | the list of the releases of NW.js (`https://nwjs.io/versions.json` by default) |
 | `LAKUTATA_LANG` | the language of the tool (`zh-CN`, `zh-TW`, `en`), by default that of the environment |
 
 The tool is itself a lakutata application: its commands are the CLI actions of its controllers, served by the

package/README.zh-CN.md

@@ -20,11 +20,12 @@ lakutata create --name my-app
 |---|---|
 | `--name <name>` | 应用的名称（必填） |
 | `--id <id>` | 应用的 ID（一个包名），默认是名称的小写形式 |
+| `--bundle-id <id>` | 应用在手机系统上的标识（反向域名：`com.acme.shop`），用于手机模板：默认是 `com.example.<名称>`，应用商店不接受 |
 | `--template <template>` | 模板（不指定时为 `default`）：官方模板（`lakutata templates` 会列出）、`npm:<package>[@<version>]`、`github:<owner>/<repo>[#<ref>]`，或者一个目录 |
 | `--path <directory>` | 在哪个目录中创建项目目录，默认是当前目录 |
 | `--init` | 直接在 `--path` 目录中创建项目。这个目录必须已经存在，里面可以有文件：已有的文件会保留（模板中也有的那些会在警告中列出，需要手动合并），只有新写入的文件会填入项目的信息 |
 | `--description`、`--author`、`--license` | 应用的信息 |
-| `--with <features>` | 要启用的模板可选功能，用逗号分隔（`lakutata templates` 会列出）：`i18n`、`installer`。在终端里，如果没有给出 `--with` 或 `--yes`，会让你从列表中选择 |
+| `--with <features>` | 要启用的模板可选功能，用逗号分隔（`lakutata templates` 会列出）：`i18n`、`installer`、`win7`。在终端里，如果没有给出 `--with` 或 `--yes`，会让你从列表中选择 |
 | `--package-manager <npm\|pnpm\|yarn\|none>` | 安装依赖所用的包管理器（`none` 表示不安装）：默认是 npm，由 pnpm 或 yarn 启动工具时用对应的那个 |
 | `--no-git` | 不初始化 git 仓库 |
 | `--yes` | 直接创建项目，不询问可选功能，也不要求确认 |
@@ -34,7 +35,7 @@ lakutata create --name my-service --template service --package-manager pnpm --ye
 lakutata create --name my-service --template service --with i18n --yes
 ```
 
-每个官方模板都有 `i18n` 功能：应用的多语言消息（`lakutata/com/i18n`），放在 `src/locales` 中（`en.json`、`zh-CN.json`），并随代码一起打包。应用按每个请求的语言回复，校验错误也一样（命令行工具和 Electron 应用使用运行环境的语言）。这个功能还会加上 `i18n:check` 和 `i18n:types` 脚本。`cli`、`service` 和 `web-*` 模板还有 `installer` 功能：应用的 `lakutata.installer` 配置，以及制作安装包的脚本（在本机制作，以及在 Docker 中制作 Linux 的安装包）；在 `service` 和 `web-*` 模板中，这个功能还包括一个系统服务。
+每个官方模板都有 `i18n` 功能：应用的多语言消息（`lakutata/com/i18n`），放在 `src/locales` 中（`en.json`、`zh-CN.json`），并随代码一起打包。应用按每个请求的语言回复，校验错误也一样（命令行工具和桌面应用使用运行环境的语言）。这个功能还会加上 `i18n:check` 和 `i18n:types` 脚本。`cli`、`service` 和 `web-*` 模板还有 `installer` 功能：应用的 `lakutata.installer` 配置，以及制作安装包的脚本（在本机制作，以及在 Docker 中制作 Linux 的安装包）；在 `service` 和 `web-*` 模板中，这个功能还包括一个系统服务。`nwjs-*` 模板有 `win7` 功能：用 NW.js 0.72.0（最后一个能在 Windows 7、8 和 8.1 上运行的版本）代替模板发布时的版本，并加上制作 32 位 Windows 安装包的脚本。
 
 ### `lakutata templates`
 
@@ -242,12 +243,12 @@ macOS 的可执行文件使用临时签名（ad hoc）。用 Node.js 制作的 W
 | `productName` | 显示给用户的名称（在安装程序中，以及 Windows 的程序列表中），默认取 `package.json` 的 `productName`，没有时取名称 |
 | `description`、`maintainer`、`homepage`、`license` | 默认取自 `package.json`（维护者是它的作者） |
 | `vendor` | 供应商，默认没有（在 Windows 上，发布者是供应商，没有时是维护者） |
-| `runtime` | 可执行文件的运行时：`node`（默认）或 `bun`；Electron 应用用 `electron`（见下文） |
-| `addToPath` | 把程序加入 PATH（`/usr/bin/<program>`，macOS 上是 `/usr/local/bin/<program>`；Windows 上是机器的 PATH），默认 `true` |
+| `runtime` | 可执行文件的运行时：`node`（默认）或 `bun`；Electron 应用用 `electron`，NW.js 应用用 `nwjs`（见下文） |
+| `addToPath` | 把程序加入 PATH（`/usr/bin/<program>`，macOS 上是 `/usr/local/bin/<program>`；Windows 上是机器的 PATH），默认 `true`（NW.js 应用默认 `false`） |
 | `service` | `true` 或服务的选项（见下文），默认没有 |
 | `linux.targets` | glibc 系统上可以是 `deb`、`rpm`、`archlinux`、`tar.gz`（默认 `deb`、`rpm`、`tar.gz`）；Alpine（musl）上是 `apk`、`tar.gz` |
 | `linux.depends`、`linux.recommends`、`linux.section`、`linux.priority` | 依赖和推荐的系统软件包、分类和优先级（deb） |
-| `mac.targets` | `pkg`、`tar.gz`（默认两种都制作） |
+| `mac.targets` | `pkg`、`tar.gz`（默认两种都制作）；NW.js 应用还可以用 `dmg` |
 | `win.targets` | `nsis`、`msi`、`zip`（默认全部制作） |
 | `electron` | Electron 应用的 electron-builder 配置，合并到由这些选项生成的配置之上 |
 
@@ -313,11 +314,82 @@ Electron 应用（`"runtime": "electron"`）的安装包由 electron-builder 制
 
 在 Linux arm64 上，fpm 软件包需要系统中的 fpm（`gem install fpm`、`USE_SYSTEM_FPM=true`），因为 electron-builder 下载的那个是为 x64 构建的。在 Windows arm64 上，NSIS 安装程序用 BCJ 过滤器压缩可执行文件（`ELECTRON_BUILDER_7Z_FILTER`），因为 7-Zip 默认会选用 ARM64 过滤器，而 NSIS 安装程序无法解压用它压缩的文件。
 
+NW.js 应用（`"runtime": "nwjs"`）的安装包里是它所用 NW.js（`lakutata nwjs use`，见下文）的 normal 版本，以应用的名字命名，应用放在其中：为这个 NW.js 的 Node.js 打包的代码、处理成能在其中加载的原生插件、资源和 NW.js 的清单。Windows 上的可执行文件是 `<name>.exe`，带有应用的图标和版本信息；macOS 上的应用包是 `<productName>.app`，它的 `Info.plist` 给出应用的名称、`appId`、版本和图标（并重新做临时签名）。它的安装包是桌面应用的安装包，默认 Linux 上是 `deb`，macOS 上是 `dmg`，Windows 上是 `nsis`：Windows 的安装程序（`nsis`、`msi`）把应用加到开始菜单和桌面，`dmg` 磁盘映像里是应用和一个指向 /Applications 的链接，`pkg` 安装包把应用装到那里，Linux 的软件包（`deb`、`rpm`）添加应用的桌面入口和图标，并依赖 Chromium 所需的库。`--arch` 为本机以外的架构制作安装包（`ia32`：32 位 Windows）。NW.js 应用不是服务；它的脚本和其他应用一样执行（macOS 上的应用是直接删除的，没有卸载脚本）。
+
 | 命令选项 | |
 |---|---|
 | `--target <targets...>` | 要制作的安装包，默认是配置中的那些 |
 | `--outdir <directory>` | 安装包的输出目录，默认 `dist/installer` |
 | `--entry`、`--no-minify`、`--external` | 与 `lakutata package exe` 相同 |
+| `--arch <arch>` | NW.js 应用的架构（`x64`、`ia32`、`arm64`），默认是本机的架构 |
+
+## NW.js
+
+NW.js 应用（`nwjs-react` 和 `nwjs-vue` 模板）运行在它 `package.json` 中指定的 NW.js 版本里：`"lakutata": {"nwjs": {"version": "0.119.2"}}`。NW.js 的运行时只下载一次到 lakutata 的缓存目录（从 `https://dl.nwjs.io` 下载，或者从 `LAKUTATA_NWJS_MIRROR` 指定的镜像下载），并按其发布版本的校验和核对。lakutata 支持内置 Node.js 为 18.10 或更高版本的 NW.js。
+
+### `lakutata nwjs versions`
+
+列出 lakutata 支持的 NW.js 版本，从新到旧：发布日期、内置的 Node.js 和 Chromium、提供的构建，并标出最新版本和最后一个能在 Windows 7 上运行的版本（`win7`，0.72.0）。默认列出最新的十个版本和 Windows 7 的那个版本，`--all` 列出全部。版本列表（`https://nwjs.io/versions.json`，或者 `LAKUTATA_NWJS_VERSIONS` 指定的列表）缓存一天。
+
+### `lakutata nwjs use <version>`
+
+为当前目录的应用设置 NW.js 版本：某个版本（`0.119.2`）、`latest` 或 `win7`，以具体的版本号写进 `package.json` 的 `lakutata.nwjs`。它同时写入 `nwjs.json`，即这个版本及其内置的 Node.js 和 Chromium，模板里用户界面的构建会读取它，以这个 Chromium 为目标；命令还会给出这个版本能运行的系统。`--download` 立即为本机下载它的 sdk 版本。
+
+### `lakutata nwjs run [args...]`
+
+在 NW.js 中运行当前目录下编译好的应用：应用先被打包到 `.nwjs/app`，以这个 NW.js 的 Node.js 为目标，带上资源和处理成能在其中加载的原生插件，然后带着 `--` 之后的参数运行（`lakutata nwjs run -- --ui=http://localhost:5173`）。NW.js 退出时命令结束；命令被终止时，NW.js 也会随之结束。
+
+| 选项 | |
+|---|---|
+| `--release <version>` | 运行的 NW.js 版本（某个版本、`latest`、`win7`），默认是 `lakutata.nwjs` 中的版本 |
+| `--flavor <sdk\|normal>` | `sdk`（默认：带 DevTools）或 `normal`（安装包中的版本） |
+
+## 手机应用
+
+按 `mobile-react` 模板布局的 React Native 手机应用（Android、iOS、鸿蒙）在一个 libnode 中运行 `packages/app` 里的应用，libnode 是应用的原生模块（`packages/ipc/native`）内嵌的 Node.js 库；各系统的原生工程在项目根目录，界面在 `packages/ui` 中。下面的命令可以在项目的任何目录中执行，用来下载 libnode、生成应用的 Node.js 项目、运行应用，并在开发时部署这个项目。
+
+### `lakutata mobile node <platform>`
+
+从 [lakutata/libnode](https://github.com/lakutata/libnode) 的 Release 下载一个系统（`android`、`ios` 或 `harmony`）的 libnode，放到 `packages/ipc/native/node/out/<platform>`，原生工程对它编译；鸿蒙的 `libnode.so` 还会放进 HAP 的库目录（`harmony/entry/libs/arm64-v8a`）。它的压缩包（`libnode_<platform>_<arch>.tar.gz`，每种架构一个）会用 Release 的 `SHA256SUMS` 校验，保存在 lakutata 的缓存目录中（`~/.cache/lakutata/mobile`），所以只下载一次。项目里还没有某个系统的 libnode 时，`lakutata mobile stage` 会先下载它。
+
+- `LAKUTATA_LIBNODE_MIRROR` 指定 Release 的镜像，文件的布局和 GitHub 上一样（`<镜像>/v<版本>/libnode_android_arm64.tar.gz`、`<镜像>/v<版本>/SHA256SUMS`）。
+- `LAKUTATA_MOBILE_NODE_DIR` 指定自己编译的 libnode（用 lakutata/libnode 仓库编译），每个系统一个目录（`android`、`ios`、`harmony`），和它导出的结构一样。
+
+| 选项 | |
+|---|---|
+| `--abis <列表>` | Android 的架构，用逗号分隔（`arm64-v8a,armeabi-v7a,x86_64`），默认是 `arm64-v8a,x86_64` |
+
+### `lakutata mobile stage <platform>`
+
+把应用的 Node.js 项目生成到系统的原生工程读取它的位置：`android/app/src/main/assets/nodejs`（应用第一次启动时复制到应用的文件目录）、`ios/nodejs`（构建应用时放进应用包）或 `harmony/entry/src/main/resources/resfile/nodejs`（直接从 HAP 的资源中运行）。项目包含面向 libnode 中 Node.js 版本的应用单文件包、资源、`package.json` 和入口；在没有 WebAssembly 的地方（鸿蒙），入口会收起 `fetch()`。
+
+依赖里的原生插件会从各自包的源码（`binding.gyp`）为目标系统编译，用的是 libnode 的头文件和库。Android 上 libnode 的每种架构各有一棵原生树，用 node-gyp 和 NDK 编译（Android SDK 里最新的 NDK，或 `ANDROID_NDK_HOME`）；自带 Android 预编译插件（`prebuilds/android-<arch>`）的包直接用它们。iOS 上（在 macOS 中）每个插件分别为真机和模拟器编成一个 framework，用 Xcode 编译到 `ios/NodeAddons` 中，构建应用时嵌进应用。编译时用的是插件的包写给 macOS 的设置（它的 `binding.gyp` 以及 node-addon-api 的 gyp 文件里 `OS=="mac"` 的部分），SDK、架构和部署版本则是 iOS 的。鸿蒙上每个插件编成 HAP 里的一个库（`harmony/entry/libs/arm64-v8a` 中的 `libaddon-<包>-<文件>.so`），用 DevEco Studio 的原生 SDK 编译（或 `OHOS_NDK_HOME`）。编译结果保存在 lakutata 的缓存目录中。
+
+| 选项 | |
+|---|---|
+| `--abis <列表>` | 为哪些 Android 架构编译插件，默认是 libnode 的那些架构 |
+| `--no-minify` | 不压缩单文件包 |
+
+### `lakutata mobile run <platform>`
+
+构建并运行系统的调试版应用，界面从 Metro（`npm start`）加载。已安装应用里的 Node.js 项目会替换之前部署进去的副本。
+
+- Android：在正在运行（或指定）的模拟器或设备上，用 Gradle 按它的架构构建、安装，让它能访问 Metro（`adb reverse`），然后启动。adb 从 Android SDK（`ANDROID_HOME`）中查找，找不到时用 `PATH` 中的。
+- iOS：在模拟器上（指定的那个，没有指定时用正在运行的那个，都没有时用最新的 iPhone，需要时先启动它），`Podfile` 有变化时先安装 pods，再用 `xcodebuild` 构建，用 `xcrun simctl` 安装、启动，并在 Simulator 或 Device Hub 中显示。
+- 鸿蒙：在已连接（或指定）的模拟器或设备上，先把界面打包进 HAP（`react-native bundle-harmony`），链接移植到鸿蒙的 React Native 库（`react-native link-harmony`，它把这些库的包加进 `harmony/oh-package.json5`），用 ohpm 安装依赖（`ohpm install --all`），再用 DevEco Studio 的 hvigor 构建（`DEVECO_STUDIO_HOME`，SDK 为 `DEVECO_SDK_HOME`），用 hdc 安装，让它能访问 Metro（`hdc rport`），然后启动。
+
+| 选项 | |
+|---|---|
+| `--device <id>` | Android 的模拟器或设备（序列号，见 `adb devices`）、鸿蒙的模拟器或设备（见 `hdc list targets`）、iOS 的模拟器（UDID 或名称，见 `xcrun simctl list devices`） |
+
+### `lakutata mobile deploy <platform>`
+
+生成项目，放进设备上已安装的调试版应用，再重新启动应用：Node.js 一侧的改动不用重新安装应用。在 Android 上写进应用的文件目录（`adb shell run-as`），并加上标记，让应用在重新安装之前一直使用它；在 iOS 上写进模拟器里的应用，连同插件的 framework；在鸿蒙上写进应用的文件目录（`hdc file send`），原生模块会优先运行它，而不是资源里的项目。原生插件只为当前设备编译（Android 只编设备的那种架构，iOS 只编模拟器版）；鸿蒙的插件是 HAP 里的库，由 `lakutata mobile run harmony` 安装。
+
+| 选项 | |
+|---|---|
+| `--device <id>` | 同 `lakutata mobile run` |
+| `--watch` | 监视应用的文件（不包括依赖和编译产物）：有变化就执行它的 `build` 脚本并重新部署，直到按 Ctrl+C |
 
 ## 迁移
 
@@ -342,7 +414,7 @@ Electron 应用（`"runtime": "electron"`）的安装包由 electron-builder 制
 | `--transaction <mode>` | 执行或撤销迁移时使用的事务：`all`（所有迁移共用一个）、`each` 或 `none`；默认取数据库的 `migrationsTransactionMode`，没有时为 `all`（`MIGRATION_TRANSACTION`） |
 | `--fake` | 只把迁移标记为已执行或已撤销，不真正执行（`MIGRATION_FAKE`） |
 
-迁移随应用一起编译，并列在所属数据库的选项中（`migrations: [...]`；设置了 `migrationsRun: true` 时，数据库连接时就会执行它们）。应用没有数据库时（`generate` 除外，这时它什么都不生成）、指定的数据库不属于应用时，以及迁移失败时，命令都会失败（退出码 1）。
+迁移随应用一起编译，并列在所属数据库的选项中（`migrations: [...]`；设置了 `migrationsRun: true` 时，数据库连接时就会执行它们）。应用没有数据库时（`generate` 除外，这时它什么都不生成，以退出码 0 结束，表结构没有变化时也一样）、指定的数据库不属于应用时，以及迁移失败时，命令都会失败（退出码 1）。
 
 ## 多语言
 
@@ -367,6 +439,8 @@ Electron 应用（`"runtime": "electron"`）的安装包由 electron-builder 制
 | `LAKUTATA_NPM_REGISTRY` | 下载模板的 npm 仓库（默认取 `npm_config_registry`，否则为 `https://registry.npmjs.org`） |
 | `LAKUTATA_GITHUB_DOWNLOAD` | 下载 `github:` 模板所用的 GitHub 镜像（默认 `https://github.com`） |
 | `LAKUTATA_CACHE_DIR` | 缓存目录（默认 `$XDG_CACHE_HOME/lakutata`，否则为 `~/.cache/lakutata`） |
+| `LAKUTATA_NWJS_MIRROR` | NW.js 运行时的下载地址（默认 `https://dl.nwjs.io`） |
+| `LAKUTATA_NWJS_VERSIONS` | NW.js 的发布版本列表（默认 `https://nwjs.io/versions.json`） |
 | `LAKUTATA_LANG` | 工具的语言（`zh-CN`、`zh-TW`、`en`），默认取环境的语言 |
 
 这个工具本身也是一个 lakutata 应用：它的命令就是其控制器的命令行动作，由入口的 commander 适配器提供。

package/dist/esm/Config.js

@@ -1,21 +1,22 @@
+import { readFileSync } from 'node:fs';
 import { buildEntrypoints } from 'lakutata/com/entrypoint';
 import { commanderCLIEntrypoint } from 'lakutata/adapter/commander';
 import { buildI18nOptions, commanderTranslator } from 'lakutata/com/i18n';
-import zhCN from './locales/zh-CN.json' with { type: 'json' };
-import zhTW from './locales/zh-TW.json' with { type: 'json' };
 import { CommandLineController } from './controllers/CommandLineController.js';
 import { WorkspaceController } from './controllers/WorkspaceController.js';
 import { PackController } from './controllers/PackController.js';
 import { MigrationController } from './controllers/MigrationController.js';
 import { NativeController } from './controllers/NativeController.js';
 import { FFIController } from './controllers/FFIController.js';
+import { NwjsController } from './controllers/NwjsController.js';
+import { MobileController } from './controllers/MobileController.js';
 import { I18nController } from './controllers/I18nController.js';
 import { LANGUAGE_VARIABLE, LanguageMiddleware } from './lib/Language.js';
 import { toolPackage } from './lib/Versions.js';
 /**
  * The controllers of the commands of the tool
  */
-export const CONTROLLERS = [CommandLineController, WorkspaceController, PackController, MigrationController, NativeController, FFIController, I18nController];
+export const CONTROLLERS = [CommandLineController, WorkspaceController, PackController, MigrationController, NativeController, FFIController, NwjsController, MobileController, I18nController];
 /**
  * The messages of the tool in the languages besides English (its texts in the code): its help, its prompts
  */
@@ -24,9 +25,19 @@ export const CONTROLLERS = [CommandLineController, WorkspaceController, PackCont
  */
 export const COMMAND_GROUPS = {
     package: 'Package the compiled application: into one JavaScript file, an executable or its installers',
-    ffi: 'Generate the classes of the native libraries of @lakutata/ffi from their C headers'
+    ffi: 'Generate the classes of the native libraries of @lakutata/ffi from their C headers',
+    nwjs: 'Give the application its version of NW.js, run it in NW.js, list the releases of NW.js',
+    mobile: 'Download the libnode of the mobile application of React Native (Android, iOS, HarmonyOS), make its Node.js project, run the application on an emulator or a simulator, deploy the project into the application installed during the development'
 };
-export const MESSAGES = { 'zh-CN': zhCN, 'zh-TW': zhTW };
+/**
+ * The messages of a language, read from its file of the locales (an import of JSON needs the import attributes, which
+ * Node.js 18.10 does not read)
+ * @param language
+ */
+function messagesOf(language) {
+    return JSON.parse(readFileSync(new URL(`./locales/${language}.json`, import.meta.url), 'utf8'));
+}
+export const MESSAGES = { 'zh-CN': messagesOf('zh-CN'), 'zh-TW': messagesOf('zh-TW') };
 /**
  * The application of the tool
  */

package/dist/esm/controllers/CommandLineController.js

@@ -22,6 +22,15 @@ import { detectPackageManager } from '../lib/Processes.js';
 import { done, styled, table } from '../lib/Output.js';
 import { frameworkVersion, latestVersion, projectFrameworkVersion, toolPackage } from '../lib/Versions.js';
 import { localize } from '../lib/Language.js';
+/**
+ * The id of an application on the mobile systems by default: com.example.<its name>, in lower case, of letters and
+ * digits only (a segment of an applicationId of Android starts with a letter)
+ * @param name
+ */
+function defaultBundleId(name) {
+    const segment = name.toLowerCase().replace(/[^a-z0-9]/g, '') || 'app';
+    return `com.example.${/^[a-z]/.test(segment) ? segment : `a${segment}`}`;
+}
 /**
  * Whether the tool runs in a terminal, where it asks the questions
  */
@@ -75,6 +84,7 @@ export class CommandLineController extends Controller {
         const plan = {
             name: input.name,
             id: input.id ?? input.name.toLowerCase(),
+            bundleId: input.bundleId ?? defaultBundleId(input.name),
             description: input.description,
             author: input.author,
             license: input.license,
@@ -89,6 +99,7 @@ export class CommandLineController extends Controller {
         process.stdout.write(table([
             [say('plan.name', 'Name'), plan.name],
             [say('plan.id', 'ID'), plan.id],
+            ...(await this.creator.uses(prepared, '{$APP_BUNDLE_ID}') ? [[say('plan.bundleId', 'Bundle ID'), plan.bundleId]] : []),
             [say('plan.description', 'Description'), plan.description || '-'],
             [say('plan.author', 'Author'), plan.author || '-'],
             [say('plan.license', 'License'), plan.license],

package/dist/esm/controllers/MigrationController.js

@@ -42,10 +42,10 @@ export class MigrationController extends Controller {
                     done(`Migrations generated: ${result.files.map(relative).join(', ')}`);
                     return undefined;
                 }
-                //The application tells why (no change of the schema, the failure)
+                //The application tells why: the failure, no change of the schemas, no database
                 if (result.code !== 0)
                     throw new Error(`No migration generated (the application exited with the code ${result.code})`);
-                done('No migration generated: the application has no Database component or provider');
+                done('No migration generated');
                 return undefined;
             }
             default: {