引入插件工作区简化和简化维护

假设您是一位插件开发者，并且拥有超过 2-3 个插件。首先，您是一个了不起的人，因为您创建了插件。做得好 👏🏻

现在假设一个新的 TypeScript 版本发布了...或者一个新的 Angular 版本...或者一个新的 Vue 版本...或者一个新的 NativeScript 版本...也许有一些重大更改或功能您现在想要集成？您现在需要维护所有插件仓库并分别更新它们，您对此感觉如何？也许您不介意？

然而，我们每次都感到不寒而栗，我们怀疑许多人也是这样。

大多数插件仓库都有自己的演示应用程序（通常是 3 个：Angular、Vue 和 Vanilla），所有这些都有自己的包依赖项、自己的 tsconfig、自己的 App_Resources，甚至自己的重复演示代码，这使得插件维护非常耗时，因为需要更新依赖项或配置。

引入插件工作区以简化生活

当我们说“简化生活”时，我们指的是为您自己和整个社区。因为我们非常喜欢您的插件！但是没有人喜欢的是，当出现一个主要版本时，我们的团队和项目必须等待插件兼容性。其他技术社区和/或框架中也存在这种情况。

我们希望解决这个问题，不仅是为了现在，还要提供一种方法，使将来在这种情况下更容易。工作区包含有用的工具，可以消除维护通常所需的许多无聊的日常工作，并真正让您专注于重要的源代码。

让我们深入了解细节。 - 或者，如果您更喜欢 观看视频，您可以在这里观看。

为什么要使用插件工作区？

工作区旨在管理一组绑定到 npm 范围的插件。

1. 将 package.json 和 tsconfig.json 更新减少到整个插件套件和演示应用程序的 1 个，而不是乘以数十个。对于源代码维护来说，这是一个巨大的改变，也是一个救星。
2. 演示插件功能可以编写一次，并在多个 NativeScript 应用程序风格中共享，以轻松舒适地确认前端框架集成合规性
3. 从管理角度和消费者角度都很清楚这些插件属于哪个 npm 范围
4. 它在结构上非常有条理
5. 您可以以一种大规模的方式自动化构建/发布任务
6. 一个不太明显但很好的好处是，它允许您作为插件作者的范围/用户名变得更显眼，因为它整齐地显示在项目的依赖项中，而不是隐藏在一个通常不会在前面看到的嵌入式包中。

如果您管理多个 npm 范围，您可以为每个范围创建一个工作区来简化您的开发生活。

设置新的插件工作区

1. 下载此仓库的 zip 文件：https://github.com/NativeScript/plugin-seed
2. 解压缩并适当地命名文件夹（也许是您打算在这里管理的 npm 范围的名称，例如 myscope - 通常这将是您的 npm 用户名或您的组织）
3. 设置工作区工具：npm run setup
4. 配置您的 npm 范围：npm run config

您的插件工作区现已设置完毕。

添加包

您现在已准备好添加要管理的工作区中的包。

npm run add

这将提示您输入要添加的包的名称。

这处理了大量通常无聊和乏味的工作，例如

• 创建 README、package.json 和准备扩展的基本级别结构
• 调整所有演示应用程序以使用新包
• 设置构建和发布任务
• 甚至创建一个可重复使用的演示结构，允许您在所有风格之间共享演示设置代码，因此您不必重复演示代码

注意：您也可以轻松地引入现有的插件 - 查看此内容以供参考

构建包

npm start

这将打开一个交互式显示，阐明在工作区中可以做什么。您可以键入 {package-name}.build 以自动向下钻取到构建任务列表并按 ENTER 键。

您的包现在已构建到 dist/packages/{package-name} 并准备发布到 npm。

构建工具会自动处理将您的 README、LICENSE、类型和平台（如果存在）复制进来。

Angular 集成通常也涉及相当多的日常设置，因此如果您的插件需要特定的 Angular 集成，您可以执行

npm run add-angular

您将被提示键入要添加 Angular 支持的包的名称。

注意：通常，插件不需要 Angular 特定内容，除非它们提供自定义视图组件 - 并非总是如此，但在考虑您的插件是否需要 Angular 特定内容时，这是一个很好的经验法则。该工具在模块中添加了一个不错的 registerElement 行，如果您的插件需要它，则已准备就绪

这将正确设置 Angular 位，以便使用 ng-packagr 构建，以实现 Angular 合规性，现在以及未来。

演示该包

当您使用 npm run add 时，它已经添加了一个可共享的演示结构，允许您编写一次演示代码，并且只需在所有演示风格中使用它即可。

您始终可以在：tools/demo/{package-name}/index.ts 中找到它

这是一个可以管理所有演示代码的类。它在所有演示中自动扩展，因此您可以将演示视图标记绑定到您编写过一次的代码。

例如

• tools/demo/awesomeplugin/index.ts:

import { DemoSharedBase } from '../utils';
// ready for you to bring classes and symbols in to test out
import { } from '@myscope/awesomeplugin';

export class DemoSharedAwesomeplugin extends DemoSharedBase {
	testIt() {
		console.log('test awesomeplugin!');
	}
}

发布该包

测试完您的包并认为它已准备好发布后，请将其发布到 npm！

• 确认您包的 package.json 详细信息。
• 确认您包的 README.md 反映了一些关于使用方面的有帮助的内容。

注意：请确保您已登录要发布的 npm 用户名。

npm whoami // 确认是否已登录以及哪个用户名 npm login // 登录

npm run publish-packages

您可以键入单个包名、用逗号分隔的包列表，或者不键入任何内容并按 Enter 键以发布工作区中的所有包。然后，系统将提示您输入显式版本，或者您只需按 Enter 键即可自动将修订版本向上提升（这也处理 alpha、beta、rc semver 版本字符串）。

10 个到 100 个包的可扩展性

无论您在工作区中管理 1 个、几个还是 100 个包，该工具都能满足您的需求。为了避免精神负担并提高专注力和效率（以及 IDE 速度），您可以利用专注模式进行独立的插件开发。我们一直在使用它们。

npm start

在交互式显示的底部选择某个包的专注模式。这将隔离所有演示应用程序以排除任何其他包的源代码，并将其依赖项向下钻取到仅包含专注的包。此外，如果使用 VS Code，它还将额外地隔离 IDE 的文件树，使其仅包含专注的包。更多 IDE 支持即将推出。

您可以使用 npm start 交互式菜单中的 focus.reset 选项将焦点重置为带回所有包并重置所有演示。

未来维护

啊，是的！这确实是使用工作区的最大好处。它基于 Nrwl 的出色 Nx 开发工具，该工具提供有用的工具，允许 TSC 在进行改进或包依赖项更改时引入新的迁移，从而帮助插件开发者获得 NativeScript 的最新更改，从而最大限度地减少每个人维护其插件所需的劳动力。

事实上，我们很快就会添加第一个迁移，它会自动添加 Vue、React 和 Svelte 演示应用程序风格，这些风格已经为您的工作区设置好了，因此您今天编写的任何演示代码都可以轻松地绑定到这些额外的风格中的视图，以便您使用流行的 NativeScript 集成来享受演示插件的乐趣。