#Sencha Cmd包
Sencha Cmd包含Sencha包管理器。包的设计主要为了解决两个问题：吞吐量和分布式开发。
## 包文件夹
所有的工作空间在根目录都有一个由Sencha Cmd生成的"packages"文件夹。它的位置是可以配置的，但不管它位置在哪里，它的功能都是存放工作空间中应用程序使用的所有的包。
packages/ # Container folder for shared Cmd packages
local/ # Folder for packages generated in this workspace
remote/ # Folder for packages downloaded into the workspace
使用命令：sencha generate package可以生成包，位置位于”packages/local"。
## 在应用中引用包
不管包的位置在哪里（本地创建或是人远程仓库下载-如下代码所示），使用包的方式都是相同的：你只需要在“app.json”文件的requires数组里添加入口即可。为了演示，我们在下面代码里添加了一个简单的包，你可以使用它。
{
"name": "MyApp",
"requires": [
"cool-stuff"
]
}
添加了上述引用后，sencha app build与sencha app refresh都会执行相应的操作将包集成到你的应用里。一般来说，在改变包的引用后，你需要运行sencha app refresh以便将开发模式需要的元数据更新到最新。
不管你执行哪个命令，Sencha Cmd都会下载包并将包解压到"packages/remote"文件夹。之后，你便在你的工作空间中发现一个"packages/remote/cool-stuff"文件夹。
## 本地包
包的一个用处是存放代码或主题以供工作空间中的多个应用使用。这些包不需要被分发(不受源代码控制管理)。
生成一个包的命令：
sencha generate package common
此命令生成一个位于"packages/local/common"里的新包。在包的配置文件里，它也会被标记为local:true。这个标记防止Sencha Cmd从远程仓库下载版本覆盖掉此包。如果在之前的版本发布里，通过修改”workspace.json“将包文件夹合并在一起，这个标记就十分重要。
在app.json里引用包：
{
"name": "MyApp",
"requires": [
"common"
]
}
## 远程包
虽然本地包在大型应用程序中非常有价值，但包中最有用的一个方面是能够为其他人提供分发包。我们使用包存储库共享和分发包。Sencha Cmd自动创建了一个“本地存储库”，用于缓存包和发布包。在本指南中没有讨论本地存储库用于包创建的功能。
有关该主题的详细信息请参见文章”创建Sencha Cmd包“。
### 本地存储库
•许多操作隐式地使用本地存储库。当Sencha Cmd遇到“app.json”中的requires语句时，它遵循如下这些基本步骤：
•在工作区中查看包是否已经存在。
•检查本地存储库，看看是否已经下载了一个版本。
•查看定义的远程存储库，查看是否有包。
•从远程存储库中下载包并添加到本地存储库。
一旦下载了包，对这个包的后续引用（requires）就不需要再下载了;该包将在本地存储库中找到。
#### 本地存储库的位置
本地存储库是在“旁边”的一个文件夹中创建的，以方便缓存。
例如，用户Foo上的Sencha Cmd的默认安装目录可能是这样的:
C:\Users\Foo\bin\Sencha\Cmd\n.n.n.n
基于如上安装目录，本地存储库将位于:
C:\Users\Foo\bin\Sencha\Cmd\repo
这可以通过编辑位于Sencha Cmd安装文件夹中的“sencha.cfg”文件来改变该位置。
### 远程存储库
为了将包下载到本地存储库，Sencha Cmd必须了解远程存储库。
在默认情况下，Sencha Cmd自动将Sencha包存储库添加为一个名为“Sencha”的远程存储库。
要查看远程存储库的列表，请运行sencha存储库列表命令:
> sencha repository list
...
[INF] Remote repository connections (1):
[INF]
[INF] sencha - http://cdn.sencha.com/cmd/packages/
您可以使用sencha repository add和sencha repository remove命令，从这个列表中添加和删除存储库。
如果您选择托管它，那么您的本地存储库实际上是一个有效的远程存储库。
## 包目录
可使用的包集在“目录”中列出。
您可以使用以下命令显示全局目录（Catalog）的内容:
sencha package list
当您列出包时，您会注意到该清单包括名称和版本。
### 包的命名
因为Sencha Cmd的存储库管理是分布式的，您可以在您认为合适的情况下添加或删除远程存储库，所以没有通用的包名称空间。如果您保留了sencha包存储库的默认“sencha”连接，那么您可以将该存储库的内容视为一个命名标准。
Sencha发布的包(不包括在Sencha框架内)将使用以下形式的名称:
sencha - *
ext - *
touch- *
cmd - *
所有从上面的前缀开始的包名都是由Sencha对Sencha包存储库保留的。
建议您避免与这些命名冲突，即使您与Sencha包存储库断开连接。
## 版本管理
要连接包和它们的消费者(即应用程序或其他包)，考虑所涉及的版本是很重要的。
为了帮助管理这个问题，所有的包都有版本号，这些版本号被requires语句用来处理版本限定。
### 包版本
所有的包都是由它们的名称和版本的组合来描述的。
然而，对于包的每个版本，都有另一个版本号来描述其向后兼容性的级别。
这个版本是由包创建者所声明，他们相信他们的包的特定版本可以向后兼容某些特定的以前版本级别。
在“package.json“文件中的描述符有两个重要的属性:version和compatVersion。
例如:
{
...
"version": "n.n.n",
"compatVersion": "2.4.2",
...
}
这个版本号必须是这种格式:
\d+(\.\d+)*
### 版本限定
在使用上面的requires属性时，我们只指定了包名，以使示例尽可能简单。这表示使用“最新版本”。
在某些情况下，这是可以接受的，但是如果包的下一个版本是完全重新设计并且没有提供向后兼容的级别，那么它可能是一个有风险的引用。
为了保护您的应用程序避免此种问题，我们可以将需求声明更改为严格声明，并锁定我们想要的版本号:
{
"name": "MyApp",
"requires": [
"[email protected]"
]
}
这种方法有它的适用性，但是它甚至阻止了包的维护版本的使用。
在项目的最后阶段，这可能正是我们想要的，但是在开发过程中，也许我们想要少一些限制，并且接受任何兼容的版本。
以下的变化将会实现向后兼容到指定版本:
{
"name": "MyApp",
"requires": [
"[email protected]?"
]
}
上面引用的是最新版本的“ext-easy-button”，它将自己描述为向后兼容1.0版本。
其他限制版本匹配的方法是:
•-1.2(没有更低的限制，最多为1.2版本)
•1.0-(没有上限-1.0或更高版本)
•1.0+(与上面的版本1.0或更高版本相同)
•1.0-1.2(版本1.0到1.2版本)
•1.0 - -1.2吗?
(兼容版本1.0，包含1.2版本)
### 解决版本问题
考虑到所有引用的和可用的版本，Sencha Cmd将决定最好的匹配包，并确保这些包在您的工作空间中。
如果存在相互排斥的引用，这个过程可能会失败。
在这种情况下，您将看到一条错误消息，解释了哪些引用（requires）是无法满足的。
Sencha Cmd包含Sencha包管理器。包的设计主要为了解决两个问题：吞吐量和分布式开发。
## 包文件夹
所有的工作空间在根目录都有一个由Sencha Cmd生成的"packages"文件夹。它的位置是可以配置的，但不管它位置在哪里，它的功能都是存放工作空间中应用程序使用的所有的包。
packages/ # Container folder for shared Cmd packages
local/ # Folder for packages generated in this workspace
remote/ # Folder for packages downloaded into the workspace
使用命令：sencha generate package可以生成包，位置位于”packages/local"。
## 在应用中引用包
不管包的位置在哪里（本地创建或是人远程仓库下载-如下代码所示），使用包的方式都是相同的：你只需要在“app.json”文件的requires数组里添加入口即可。为了演示，我们在下面代码里添加了一个简单的包，你可以使用它。
{
"name": "MyApp",
"requires": [
"cool-stuff"
]
}
添加了上述引用后，sencha app build与sencha app refresh都会执行相应的操作将包集成到你的应用里。一般来说，在改变包的引用后，你需要运行sencha app refresh以便将开发模式需要的元数据更新到最新。
不管你执行哪个命令，Sencha Cmd都会下载包并将包解压到"packages/remote"文件夹。之后，你便在你的工作空间中发现一个"packages/remote/cool-stuff"文件夹。
## 本地包
包的一个用处是存放代码或主题以供工作空间中的多个应用使用。这些包不需要被分发(不受源代码控制管理)。
生成一个包的命令：
sencha generate package common
此命令生成一个位于"packages/local/common"里的新包。在包的配置文件里，它也会被标记为local:true。这个标记防止Sencha Cmd从远程仓库下载版本覆盖掉此包。如果在之前的版本发布里，通过修改”workspace.json“将包文件夹合并在一起，这个标记就十分重要。
在app.json里引用包：
{
"name": "MyApp",
"requires": [
"common"
]
}
## 远程包
虽然本地包在大型应用程序中非常有价值，但包中最有用的一个方面是能够为其他人提供分发包。我们使用包存储库共享和分发包。Sencha Cmd自动创建了一个“本地存储库”，用于缓存包和发布包。在本指南中没有讨论本地存储库用于包创建的功能。
有关该主题的详细信息请参见文章”创建Sencha Cmd包“。
### 本地存储库
•许多操作隐式地使用本地存储库。当Sencha Cmd遇到“app.json”中的requires语句时，它遵循如下这些基本步骤：
•在工作区中查看包是否已经存在。
•检查本地存储库，看看是否已经下载了一个版本。
•查看定义的远程存储库，查看是否有包。
•从远程存储库中下载包并添加到本地存储库。
一旦下载了包，对这个包的后续引用（requires）就不需要再下载了;该包将在本地存储库中找到。
#### 本地存储库的位置
本地存储库是在“旁边”的一个文件夹中创建的，以方便缓存。
例如，用户Foo上的Sencha Cmd的默认安装目录可能是这样的:
C:\Users\Foo\bin\Sencha\Cmd\n.n.n.n
基于如上安装目录，本地存储库将位于:
C:\Users\Foo\bin\Sencha\Cmd\repo
这可以通过编辑位于Sencha Cmd安装文件夹中的“sencha.cfg”文件来改变该位置。
### 远程存储库
为了将包下载到本地存储库，Sencha Cmd必须了解远程存储库。
在默认情况下，Sencha Cmd自动将Sencha包存储库添加为一个名为“Sencha”的远程存储库。
要查看远程存储库的列表，请运行sencha存储库列表命令:
> sencha repository list
...
[INF] Remote repository connections (1):
[INF]
[INF] sencha - http://cdn.sencha.com/cmd/packages/
您可以使用sencha repository add和sencha repository remove命令，从这个列表中添加和删除存储库。
如果您选择托管它，那么您的本地存储库实际上是一个有效的远程存储库。
## 包目录
可使用的包集在“目录”中列出。
您可以使用以下命令显示全局目录（Catalog）的内容:
sencha package list
当您列出包时，您会注意到该清单包括名称和版本。
### 包的命名
因为Sencha Cmd的存储库管理是分布式的，您可以在您认为合适的情况下添加或删除远程存储库，所以没有通用的包名称空间。如果您保留了sencha包存储库的默认“sencha”连接，那么您可以将该存储库的内容视为一个命名标准。
Sencha发布的包(不包括在Sencha框架内)将使用以下形式的名称:
sencha - *
ext - *
touch- *
cmd - *
所有从上面的前缀开始的包名都是由Sencha对Sencha包存储库保留的。
建议您避免与这些命名冲突，即使您与Sencha包存储库断开连接。
## 版本管理
要连接包和它们的消费者(即应用程序或其他包)，考虑所涉及的版本是很重要的。
为了帮助管理这个问题，所有的包都有版本号，这些版本号被requires语句用来处理版本限定。
### 包版本
所有的包都是由它们的名称和版本的组合来描述的。
然而，对于包的每个版本，都有另一个版本号来描述其向后兼容性的级别。
这个版本是由包创建者所声明，他们相信他们的包的特定版本可以向后兼容某些特定的以前版本级别。
在“package.json“文件中的描述符有两个重要的属性:version和compatVersion。
例如:
{
...
"version": "n.n.n",
"compatVersion": "2.4.2",
...
}
这个版本号必须是这种格式:
\d+(\.\d+)*
### 版本限定
在使用上面的requires属性时，我们只指定了包名，以使示例尽可能简单。这表示使用“最新版本”。
在某些情况下，这是可以接受的，但是如果包的下一个版本是完全重新设计并且没有提供向后兼容的级别，那么它可能是一个有风险的引用。
为了保护您的应用程序避免此种问题，我们可以将需求声明更改为严格声明，并锁定我们想要的版本号:
{
"name": "MyApp",
"requires": [
"[email protected]"
]
}
这种方法有它的适用性，但是它甚至阻止了包的维护版本的使用。
在项目的最后阶段，这可能正是我们想要的，但是在开发过程中，也许我们想要少一些限制，并且接受任何兼容的版本。
以下的变化将会实现向后兼容到指定版本:
{
"name": "MyApp",
"requires": [
"[email protected]?"
]
}
上面引用的是最新版本的“ext-easy-button”，它将自己描述为向后兼容1.0版本。
其他限制版本匹配的方法是:
•-1.2(没有更低的限制，最多为1.2版本)
•1.0-(没有上限-1.0或更高版本)
•1.0+(与上面的版本1.0或更高版本相同)
•1.0-1.2(版本1.0到1.2版本)
•1.0 - -1.2吗?
(兼容版本1.0，包含1.2版本)
### 解决版本问题
考虑到所有引用的和可用的版本，Sencha Cmd将决定最好的匹配包，并确保这些包在您的工作空间中。
如果存在相互排斥的引用，这个过程可能会失败。
在这种情况下，您将看到一条错误消息，解释了哪些引用（requires）是无法满足的。