创建 Sencha Cmd 包

Sencha Cmd 包含了 Sencha Package Manager。即使您不打算分发您创建的包，包也有许多用途。本指南介绍了创建您自己的包以及分发它们的过程。有关使用包的信息，请参阅 Sencha Cmd 包。

生成包

在我们生成新包之前，我们必须首先为其创建一个家：一个 Workspace。对于此示例，我们将为此包使用 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" - Mixins 和规则（镜像 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 主题使用此机制来更改各种组件上的某些默认配置属性。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" 文件用于将包添加到您的本地仓库。请参阅下文。

框架

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

"framework": "ext"

主题

您需要手动将 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 都可以工作。