NativeScript 8.1 是一个错误修复和稳定性版本，并增加了一些期待已久的功能。
此版本是在过去几个月社区积极参与 alpha、beta 和 rc 版本测试的基础上发布的，这有助于识别各种生产环境中的关键问题。我们感谢社区的持续支持和见解。
我们的 路线图 现已在首页提供。它展示了过去的成就以及未来的计划。此路线图将在后续版本中更新，以完成突出显示的项目，并根据需要调整以包含其他计划的项目，以便您随时参考。与往常一样，请 考虑参与 RFC 讨论，以帮助影响 NativeScript 的未来。
更新到任何次要或主要版本的 NativeScript 通常从安装最新的 CLI 开始，让我们开始吧。
npm i -g nativescript
# then in your projects:
ns migrate
注意：CLI 可以与旧项目一起使用，因此始终建议运行最新的 CLI，无论项目版本如何。
这将安装最新的 NativeScript CLI，然后运行迁移以更新您的项目。
以下是您在成功迁移后可以预期使用的依赖项
"dependencies": {
"@nativescript/core": "~8.1.1"
},
"devDependencies": {
"@nativescript/android": "~8.1.1",
"@nativescript/ios": "~8.1.0",
"@nativescript/types": "~8.1.0",
"@nativescript/webpack": "~5.0.0"
}
CLI 已更新，以正式支持“工作区开发”。多年来，一些出色的工作区风格 (monorepo) 工具已成为可扩展软件开发不可或缺的一部分，包括但不限于 Lerna、Yarn 工作区、Nrwl Nx 和 Microsoft Rush。
从历史上看，NativeScript CLI 使用特定的 Node API，这限制了可以开发 NativeScript 的开发风格。
从 8.1 开始，在整个过程中进行了一些路径解析更改，以扩展 NativeScript 应用程序集成到这些流行的工作区工具中的灵活性。
考虑以下一般工作区结构
apps/
mobile-app-a/
package.json
mobile-app-b/
package.json
package.json
在 8.1 之前，您可以在工作区中的每个 NativeScript 应用程序中使用相对的 file: 路径在工作区中共享依赖项
"@nativescript/core": "file:../../node_modules/@nativescript/core",
"another-package": "file:../../node_modules/another-package",
这有点笨拙且难以管理。它还会导致更长的安装时间和更深的 package.json 树需要维护，这有时会导致意外的结果。
使用 8.1，您现在可以通过设置 CLI 包管理器来正确使用 yarn 工作区等工具来管理依赖项树
ns package-manager set yarn
您甚至可以将 Yarn 工作区 与 Nrwl Nx 相结合，以享受使用 NativeScript 应用程序改进的依赖项管理。
例如，您现在可以执行以下操作
apps/
mobile-app-a/
package.json
{
"dependencies": {
"@nativescript/core": "*"
}
}
mobile-app-b/
package.json
{
"dependencies": {
"@nativescript/core": "*"
}
}
package.json
{
"workspaces": [
"apps/mobile-app-a",
"apps/mobile-app-b"
],
"dependencies": {
"@nativescript/core": "~8.1.0",
"@nativescript/webpack": "~5.0.0"
}
}
运行 yarn 安装依赖项将允许 mobile-app-a 和 mobile-app-b 都使用根包中固有的 @nativescript/core 版本，此外不再需要在每个应用程序中安装该包。
在这种情况下，为什么每个 NativeScript 应用程序都需要在其中指定任何依赖项？
NativeScript 依赖项通常会为 iOS 或 Android 引入其他原生依赖项（例如，通过 npm 上提供的 NativeScript 插件使用 CocoaPods、gradle 插件等）。通过在每个应用程序的 package.json 中列出 NativeScript 依赖项，您可以明确哪些原生依赖项包含在您根工作区管理的 package.json 中。这使您能够在工作区中的多个应用程序之间共享和使用不同的 NativeScript 插件，而不是通过在根目录中管理的 NativeScript npm 插件自动附加任何原生代码。
经验法则 👍：在工作区中的每个应用程序中使用 "*" 包含 NativeScript 插件，以及它们应该分别使用的运行时 devDependencies。
要探索这在实践中的意义，您可以使用以下两种示例工作区设置进行尝试
以前，在 iOS 上生成类型需要知道要设置的特定环境级别变量，并且对于 Android，需要下载并运行一个工具。
在 8.1 中，我们添加了一个新的 ns typings 命令，以帮助根据需要从原生依赖项生成 .d.ts 文件。
ns typings android [ --jar <Jar1> --jar <Jar2> ] [ --copy-to <Path> ] [ --aar <Aar1> ]
ns typings ios [ --copy-to <Path> ] [ --filter <Filter> ]
请注意，这些标志是可选的。默认情况下，类型将生成在您从中执行命令的目录中的 typings 文件夹中，但是您可以使用 --copy-to 标志指定不同的文件夹名称或完全不同的路径。
注意：--aar 和 --filter 选项目前尚未实现，但计划在未来版本中进行改进。
使用 8.1，插件现在可以在 platforms/android 文件夹内包含 Kotlin 源文件。
// platforms/android/java/org/nativescript/plugins/sample/KotlinWorks.kt
package org.nativescript.plugins.sample
class KotlinWorks {
val hello = "Hello from Kotlin!"
}
const kotlinWorks = new org.nativescript.plugins.sample.KotlinWorks()
console.log(kotlinWorks.hello)
// prints: Hello from Kotlin!
已添加一个新的环境标志以允许远程 adb 设备工作
NATIVESCRIPT_LIVESYNC_ADDRESS="192.168.0.50" ns run android
这允许 Android 文档中记录的无线调试。
另一个用例是，如果您有远程模拟器并运行 adb 服务器（例如使用 adb -a -P 5555 nodaemon server），您可以将本地 adb 配置为连接到此服务器并在远程运行应用程序
export ANDROID_ADB_SERVER_ADDRESS=192.168.0.50
export ANDROID_ADB_SERVER_PORT=5555
NATIVESCRIPT_LIVESYNC_ADDRESS="192.168.0.50" ns run android
注意：这只是一个示例，远程 adb 连接可能需要其他配置。
--config 选项您现在可以传递一个可选的 --config 选项以从与默认 nativescript.config.ts 不同的文件中加载配置。
建议坚持使用默认设置，但此选项允许一些灵活性，例如在生产中使用不同的配置
ns build android --config=nativescript.config.prod.ts
# will load the values from 'nativescript.config.prod.ts'
重复的原生依赖项将不再多次构建。以前，这可能发生在共享公共基础库的插件（如 @nativescript-community/ui-material-* 插件）中。
此版本中包含许多其他 QOL 更改，请参阅 此处查看完整更改日志。
在 8.1 中，核心获得了一些不错的错误修复、功能和改进。以下是简要概述
这只是对核心更改的简要概述 — 请参阅 此处查看完整更改日志。
在 8.1 中，包含了一些内存优化，以及将内部 v8 引擎更新到 9.2.230.18。
特别是 c 字符串参数处理已得到优化，这将提高使用 SQLite 数据库的应用程序的内存占用。
有关更改的完整列表，请参阅 此处查看完整更改日志
在 8.1 中，包含了一些维护更新和错误修复，最值得注意的是
为了准备 iOS 15 和 Android 12，您将在最新的类型中找到这两个新的 API
我们在今年（2021 年）4 月的 beta 版本中开始使用 webpack 5。几个月来，我们将其用于高速项目和生产部署，使我们能够使用 NativeScript 项目稳定许多新的 webpack5 API，我们很高兴今天能够使用它，它可以实现更快的构建和稳定的 5.0.0 版本。
您可以 在此处查看版本说明。
如果您仍在使用 @nativescript/webpack ~4.1.0（或更早版本），您可能会看到类似这样的错误 😱
System.err: An uncaught Exception occurred on "main" thread.
System.err: Calling js method getView failed
System.err: ReferenceError: __UI_USE_EXTERNAL_RENDERER__ is not defined
要使用 8.1，您需要通过调整 DefinePlugin 规则来修改您的 webpack.config.js
new webpack.DefinePlugin({
'global.TNS_WEBPACK': 'true',
'global.isAndroid': platform === 'android',
'global.isIOS': platform === 'ios',
process: 'global.process',
// add these 3 lines
__UI_USE_XML_PARSER__: true,
__UI_USE_EXTERNAL_RENDERER__: false,
__CSS_PARSER__: JSON.stringify('css-tree')
}),
我们发布了 @nativescript/tailwind 的更新版本，之前发布为 nativescript-tailwind，它将出色的 Tailwind CSS 支持引入 NativeScript。虽然之前可以使用，但此更新的包与 @nativescript/webpack 一起使用，使其比以往任何时候都更容易
npm install --save @nativescript/tailwind tailwindcss
然后更改您的 app.css 或 app.scss 文件以包含 tailwind
@tailwind components;
@tailwind utilities;
就是这样——@nativescript/tailwind 将使用新的 @nativescript/webpack API 自动连接所有其他内容。您可以使用一些 tailwind 测试所有内容是否正常工作
<label text="TailwindCSS is awesome!" class="px-2 py-1 text-center text-blue-600 bg-blue-200 rounded-full" />
也可以，甚至**建议**使用 Tailwind 的新 JIT（即时）模式，在 tailwind.config.js 中进行设置。首先，我们需要使用 npx 创建配置文件
npx tailwindcss init
然后将其更改为启用 jit 模式
// tailwind.config.js
module.exports = {
mode: 'jit',
purge: ['./app/**/*.{css,xml,html,vue,svelte,ts,tsx}'],
darkMode: false, // or 'media' or 'class'
theme: {
extend: {},
},
variants: {
extend: {},
},
plugins: [],
}
我们重新推出了广受欢迎的 NativeScript 示例，这些示例展示了多种创意布局、动画和应用设置。
我们重新推出了 NativeScript 展示。我们从一个小型初始列表开始，并在未来几周内继续扩展。我们很快就会添加更多关于如何提交您自己的应用的信息。在此期间，如果您希望您的应用出现在展示中，请将详细信息发送至 [email protected]
以下所有 nativescript-ui-* 插件都已更新为主要版本，以包含 .xcframework 兼容性，以便在 M1 Mac 上进行开发
在 12.2 中，添加了一些错误修复和功能。
添加了一个新选项，以减少应用中不必要的变更检测周期。它完全是可选的，但绝对可以尝试一下！
import { NativeScriptNgZone, platformNativeScript, runNativeScriptAngularApp } from '@nativescript/angular'
import { AppModule } from './app/app.module'
runNativeScriptAngularApp({
appModuleBootstrap: () =>
platformNativeScript().bootstrapModule(AppModule, {
ngZone: new NativeScriptNgZone(), // <-- new option
}),
})
**提醒**：您是否在使用带有“命名”page-router-outlet 的 loadChildren？
当在 page-router-outlet 上使用带有“命名”出口的 loadChildren 时，请确保您的路由配置包含 component: NSEmptyOutletComponent。
这对于 Angular 在后台如何处理命名出口非常重要。缺少 NSEmptyOutletComponent 将导致 Angular 路由器在 @nativescript/angular 的范围之外创建 RouterOutlet，这可能导致意外结果。
如果您的 page-router-outlet 没有 name 属性，并且您的路由配置没有引用 outlet，则此规则不适用于您。
以下是 @nativescript/angular 的变更日志
我们将从 2021 年 10 月开始，每个月的第一个星期一举行一小时的正式 NativeScript 线上办公时间。具体时间（以及时区）将很快公布。形式将是 Zoom 会议，任何人都可以加入，提出问题并讨论任何与 NativeScript 相关的内容。
如果您是编程领域的初学者，我们邀请您与充满热情、关爱且易于沟通的开源维护者进行开放且轻松的聊天。
这些将是轻松的 AMA（问我任何问题）环节，您有机会与开源维护者和专业人士交谈，涵盖从编写第一行代码到管理开源项目，再到为雇主和客户构建深入的用户体验等各个方面。
课程将每月安排一次，并在提供的时区之间协调。
资源
感谢您投资围绕 JavaScript 技术的可持续开源未来。
最后说明一点，我们一直在慢慢地将 NativeScript 社区转移到 Discord，所以如果您还没有加入，请务必加入我们！
我们要感谢令人惊叹的社区持续的投入、贡献和支持。感谢那些通过测试 alpha、beta 和 rc 版本、报告问题和贡献修复来帮助塑造 8.1 版本的人。❤️