创建 Sencha Cmd 包

Sencha Cmd 包括 Sencha 包管理器。即使您不打算分发您创建的包，包也有许多用途。本指南涵盖了创建您自己的包以及分发它们的过程。有关使用包的信息，请参阅 Sencha Cmd 包。

生成包

在我们生成新包之前，我们必须首先为其创建一个家：一个 工作区。对于此示例，我们将使用 Ext JS 来创建此包，因此我们从以下命令开始

sencha -sdk /path/to/ext-n.n.n generate workspace /path/to/workspace

现在我们导航到新的工作区并生成包

cd /path/to/workspace
sencha generate package foo

包的结构

以上步骤生成一个包含许多常用部分的入门包。您可以删除其中的许多部分，但保持 ".sencha" 文件夹完整非常重要。

由 sencha generate package 生成的包的结构如下

packages/
    local/
        foo/                        # Top-level folder for the package
            .sencha/
                package/
                    sencha.cfg      # Sencha Cmd configuration for this package
                    build-impl.xml  # Generated build script for package
                    plugin.xml      # Sencha Cmd plugin for this package
                    codegen.json    # Data to support 3-way merge in code generator
            classic/                # Classic toolkit-specific src code
            examples/               # Example applications demonstrating the package
            licenses/               # License agreement
            modern/                 # Modern toolkit-specific src code
            overrides/              # Folder for automatically activated overrides
            resources/              # Static resources (typically has images folder)
            sass/                   # Container for styling code
                etc/                # General, non-component oriented styling
                example/            # - internal use
                src/                # Style rules named by component
                var/                # Variables and mixins named by component
            src/                    # Folder for normal JavaScript code
            build.xml               # Build script (called by `sencha package build`)
            package.json            # Package descriptor
            Readme.md               # High-level information about this package

虽然上面内容非常广泛，但作为包的唯一必需部分是 "package.json" 和 ".sencha/package/sencha.cfg"。

"package.json" 文件包含包的描述。以下是 "theme-neptune" 包中的示例

{
    "name": "theme-neptune",
    "type": "theme",
    "creator": "Sencha",
    "summary": "Ext JS Neptune Theme",
    "detailedDescription": "The Neptune Theme provides a clean, modern style for Ext JS",
    "version": "n.n.n",
    "compatVersion": "n.n.n",
    "format": "1",
    "extend": "theme-neutral"
}

creator 属性是您需要设置为包作者的内容。对此文本没有验证，但它必须与您稍后分配给本地包仓库的名称匹配。

将包集成到应用程序构建中

大多数包的目的是（最终）集成到应用程序中。为了实现这一点，Sencha Cmd 在 sencha app build 过程中将每个所需包的各个部分合并到应用程序中。

这具体如何发生取决于包的 type。

包类型

不同类型的包扮演不同的角色。Sencha Cmd 理解以下类型的包

• code - 供应用程序或其他包使用的任意代码包。这些包是通用的，并且在存在选择它们的 require 语句时包含在内。
• theme - 用作应用程序主题的包。主题是特殊的，因为在构建中只允许一个 theme 类型的包处于“活动”状态。此主题由 app.json 中的 theme 属性选择。主题还可以使用 extend 从另一个主题包继承样式和资源。
• locale - 此包类型已弃用，推荐使用标准的 code 包，该包在其 classpath 中包含 theme.name。有关示例，请参阅 Ext JS locale 包。

源代码

"src" 文件夹是存放类（例如自定义组件或其他有用的代码）的位置。此代码会自动包含在应用程序或其他包的 classpath 中，以便 require 和使用。

这是您可能放置大部分 JavaScript 代码的地方。放置在此文件夹中的类应遵循 编译器友好的代码指南。

样式

"sass" 文件夹包含三个子文件夹，旨在处理样式编译的不同方面。

• "sass/etc" - 与 JavaScript 类没有直接关系的代码
• "sass/var" - 变量定义（镜像 JavaScript 类层次结构）
• "sass/src" - Mixin 和规则（镜像 JavaScript 类层次结构）

"sass/var" 和 "sass/src" 中的文件夹和文件经过组织，使其成为它们应用的 JavaScript 类的镜像图像。这种对应关系允许 Sencha Cmd 包含应用程序所需的文件。这些文件夹中不符合此规则的文件永远不会被包含，因为该过程通过将 JavaScript 类层次结构映射到文件系统来进行，而不是扫描这些文件夹。

名称对应关系由 "package.json" 中的 namespace 属性驱动

{
    "name": "MyPkg",
    ...

    "sass": {
        "namespace": "MyPkg",
        ...
}

当将所需 JavaScript 类的类名映射到相应的 .scss 文件时，命名空间会发挥作用。例如，给定类 MyPkg.foo.Bar 和上面的 namespace，Sencha Cmd 删除 "MyPkg." 并在 "sass/var" 和 "sass/src" 文件夹中查找 "foo/Bar.js" 的相对路径。

注意： 即使 Fashion 不是 Sass 的实现，“sass”配置名称也出于兼容性目的而保留。

资源

"resources" 文件夹是您放置包所需的静态资源的地方。当应用程序使用该包时，它们会将这些资源复制到它们自己的 "resources" 文件夹的子文件夹中，并以包名称命名。在本例中为 "resources/foo"。如果您使用提供的 theme-background-image 方法，CSS 文件中使用的相对路径将自动更正。

覆盖

"overrides" 文件夹专门用于您的包提供强制覆盖，因此得名。应谨慎使用此机制，因为您放置在此文件夹中的所有代码都将自动要求包含在使用此包的任何应用程序中。

Ext JS Neptune 主题使用此机制来更改各种组件上的某些默认 config 属性。Locale 包使用它来将它们自己的文本注入到各种组件的原型上，或者为日期格式化等事物提供特定于语言环境的逻辑。

包版本

包具有 version 属性，用于描述其当前版本号。此外，除了当前版本（在 version 属性中），包还可以使用 compatVersion 属性指示它们的向后兼容程度。

这些版本在解析包要求时使用。包的每个版本都应具有更新的版本号。Sencha 分配给版本号的含义可能会对您有所帮助

x.y.z.b

x = Major release number (large, impacting changes and features)
y = Minor release number (new functionality but few if any breaking changes)
z = Patch release number (bug fix / maintenance release - goal of 100% compatible)
b = Build number (assigned by build system)

version 属性通常是最容易维护的。但是，compatVersion 是关于用户应该能够在多大程度上透明地升级而无需代码更改的有意声明。

包要求

包可以像应用程序可以要求包一样要求其他包。为此，您可以添加到 requires 数组中

{
    "name": "bar",
    "type": "code",
    "creator": "anonymous",
    "summary": "Short summary",
    "detailedDescription": "Long description of package",
    "version": "1.0.0",
    "compatVersion": "1.0.0",
    "format": "1",
    "local": true,
    "requires": [
        'ext-easy-button'
    ]
}

注意：当作为包作者使用版本限制时，重要的是要考虑到应用程序和所有必需的包都必须就通用版本达成一致。如果您过于严格，此过程可能会无法为所有必需的包找到相互同意的版本。

包继承

包继承的概念专门用于主题。以下是将继承的包内容合并到派生包中的最重要方式

• 继承包的 "resources" 文件夹复制到 "build" 输出文件夹中的 "resources" 文件夹中。
• 基本包的 overrides 会自动包含在派生包的构建输出中。

构建包

要发布包，您需要使用以下命令构建它

sencha package build

这会在包内生成一个 "build" 文件夹。当应用程序在“开发模式”（未编译）下运行时，需要此文件夹。

它还在您的工作区的 "build" 文件夹中生成 "foo.pkg" 文件。此文件未放置在包的 "build" 文件夹中，因为

• 它是您的包文件夹的 ZIP 文件。
• 包的用户不需要它。

"foo.pkg" 文件用于将包添加到您的本地仓库。请参见下文。

framework

您需要手动将 package.framework 指定添加到您的 "package.json" 文件中。

"framework": "ext"

theme

您需要手动将 package.theme 指定添加到您的 "package.json" 文件中。该值将是用于生成的 CSS 的主题包的名称。

"theme": "theme-triton"

本地仓库

本地仓库在 Sencha Cmd 包 中介绍过，但是当您想要分发您创建的包时，还有更多需要了解的内容。

结构

Sencha Cmd 生成的本地仓库如下所示

.sencha/
    repo/
        sencha.cfg                  # Sencha Cmd configuration for the repo
        plugin.xml                  # Plugin for repository hooks
        private-key.json            # Private key for repo

        remotes/                    # Storage for remote repositories
            remoteName/             # Name given at `sencha repo add`
                catalog.json        # Last catalog from this remote

        trust/                      # Unused in this release
            <somename>.cert.json    # Copy of `cert.json` (a public key)

pkgs/
    catalog.json                    # Catalog of all packages in this repo
    cert.json                       # Public key for this repo

    Foo/
        catalog.json                # Catalog for all versions of Foo package
        cert.json                   # Public key for creator of Foo package

        1.0/                        # Folder containing version 1.0
            Foo.pkg                 # Zip file of package
            package.json            # Extracted package descriptor
        1.1/
            ...

    Bar/
        ...

作者身份

当 Sencha Cmd 生成默认本地仓库时，它不要求您提供任何类型的身份。这对于它作为缓存的角色来说很好，但是作为包作者，您需要在您发布的包上署名。在您可以发布包之前，您需要使用身份初始化您的本地仓库

sencha package repo init -name "My Company" -email "[email protected]"

完成此步骤后，您的姓名和电子邮件地址将与新的 公钥/私钥对 一起记录在本地仓库中。

注意：name 参数必须与您在 "package.json" 中设置的 creator 属性的值匹配。

公钥/私钥

您的姓名、电子邮件和公钥存储在 "pkgs/cert.json" 文件中。此文件将自动添加到您创建的包中，以标识您为包作者。

显然，顾名思义，您的私钥不打算与他人共享。它存储在您的本地仓库的 ".sencha/repo/private-key.json" 中。

您可能需要备份这两个文件，因为它们将在未来的版本中发挥更重要的作用。

内容

"pkgs" 文件夹是存储所有包的位置。这些可能是您创建的包或您下载的包。

当您添加包 ".pkg" 文件时，这些文件将被复制到 "pkgs" 文件夹树中。

仓库钩子

".sencha/repo/plugin.xml" 文件是一个 Ant 脚本，您可以使用它为仓库操作（例如 sencha package add）提供“钩子”。有关此的更多详细信息，请参阅生成文件中的注释。

添加包

一旦您从构建中获得 ".pkg" 文件，并且假设您在本地仓库上设置为您的身份的 name 与您的 "package.json" 中定义的 creator 属性匹配，您就可以运行此命令

sencha package add foo.pkg

Sencha Cmd 将使用您的私钥生成 ".pkg" 文件的哈希值，并将其添加到您指定的 ".pkg" 文件中，然后将该文件复制到本地仓库。

现在包驻留在仓库中，其他开发人员如果已将您的仓库添加为远程仓库，则可以 require 它。

请求 Sencha 将您的 ".pkg" 添加到 Sencha 包仓库的过程仍在最终确定中，但您可以查看 Sencha Market 以获取有关此的更新。

托管包仓库

"pkgs" 文件夹的结构是远程仓库预期的结构。其他人 require 您创建的包所需要做的就是添加远程仓库

sencha package repo add my-company http://my.company.com/packages

也就是说，假设您已将您的 "pkgs" 文件夹内容托管在上面的 HTTP URL。除了 HTTP GET 访问之外，该托管没有任何要求，因此静态文件服务器或 CDN 将工作。