##环境变量
说明：
你可以设置一些环境变量来覆盖默认的配置。建议尽可能的在 composer.json 的 config 字段中设置这些值，而不是通过命令行设置环境变量。值得注意的是环境变量中的值，将始终优先于 composer.json 中所指定的值。1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
841.COMPOSER
<!-- 环境变量 COMPOSER 可以为 composer.json 文件指定其它的文件名。如 -->
COMPOSER=composer-other.json composer install
2.COMPOSER_ROOT_VERSION
<!-- 通过设置这个环境变量，你可以指定 root 包的版本，如果程序不能从 VCS 上猜测出版本号，并且未在 composer.json 文件中申明。 -->
3.COMPOSER_VENDOR_DIR
<!-- 通过设置这个环境变量，你可以指定 composer 将依赖安装在 vendor 以外的其它目录中。 -->
4.COMPOSER_BIN_DIR
<!-- 通过设置这个环境变量，你可以指定 bin（Vendor Binaries）目录到 vendor/bin 以外的其它目录。 -->
5.http_proxy or HTTP_PROXY
<!-- 如果你是通过 HTTP 代理来使用 Composer，你可以使用 http_proxy 或 HTTP_PROXY 环境变量。只要简单的将它设置为代理服务器的 URL。许多操作系统已经为你的服务设置了此变量。
建议使用 http_proxy（小写）或者两者都进行定义。因为某些工具，像 git 或 curl 将使用 http_proxy 小写的版本。另外，你还可以使用 git config --global http.proxy <proxy url> 来单独设置 git 的代理。 -->
6.no_proxy
<!-- 如果你是使用代理服务器，并且想要对某些域名禁用代理，就可以使用 no_proxy 环境变量。只需要输入一个逗号相隔的域名 排除 列表。
此环境变量接受域名、IP 以及 CIDR地址块。你可以将它限制到一个端口（例如：:80）。你还可以把它设置为 * 来忽略所有的 HTTP 代理请求。 -->
7.HTTP_PROXY_REQUEST_FULLURI
<!-- 如果你使用了 HTTP 代理，但它不支持 request_fulluri 标签，那么你应该设置这个环境变量为 false 或 0 ，来防止 composer 从 request_fulluri 读取配置。 -->
8.HTTPS_PROXY_REQUEST_FULLURI
<!-- 如果你使用了 HTTPS 代理，但它不支持 request_fulluri 标签，那么你应该设置这个环境变量为 false 或 0 ，来防止 composer 从 request_fulluri 读取配置。 -->
9.COMPOSER_HOME
<!-- COMPOSER_HOME 环境变量允许你改变 Composer 的主目录。这是一个隐藏的、所有项目共享的全局目录（对本机的所有用户都可用）。
它在各个系统上的默认值分别为：
*nix /home/<user>/.composer。
OSX /Users/<user>/.composer。
Windows C:\Users\<user>\AppData\Roaming\Composer。 -->
10.COMPOSER_HOME/config.json
<!-- 你可以在 COMPOSER_HOME 目录中放置一个 config.json 文件。在你执行 install 和 update 命令时，Composer 会将它与你项目中的 composer.json 文件进行合并。
该文件允许你为用户的项目设置 配置信息 和 资源库。
若 全局 和 项目 存在相同配置项，那么项目中的 composer.json 文件拥有更高的优先级。
-->
11.COMPOSER_CACHE_DIR
<!-- COMPOSER_CACHE_DIR 环境变量允许你设置 Composer 的缓存目录，这也可以通过 cache-dir 进行配置。
它在各个系统上的默认值分别为：
*nix and OSX $COMPOSER_HOME/cache。
Windows C:\Users\<user>\AppData\Local\Composer 或 %LOCALAPPDATA%/Composer。
COMPOSER_PROCESS_TIMEOUT
这个环境变量控制着 Composer 执行命令的等待时间（例如：git 命令）。默认值为300秒（5分钟）。 -->
12.COMPOSER_DISCARD_CHANGES
<!-- 这个环境变量控制着 discard-changes config option。 -->
13.COMPOSER_NO_INTERACTION
<!-- 如果设置为1，这个环境变量将使 Composer 在执行每一个命令时都放弃交互，相当于对所有命令都使用了 --no-interaction。可以在搭建 虚拟机/持续集成服务器 时这样设置。 -->
php 之 composer 的命令一
##前言 帮助无疑是最好的教程
1 | <!-- 此命令将列出所有可操作的命令 --> |
#全局参数 可与任意命令使用1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28--verbose (-v): 增加反馈信息的详细度。
<!-- 1.)-v 表示正常输出。 -->
composer -v
<!-- 2.)-vv 表示更详细的输出。 -->
comoser -vv
<!-- 3.)-vvv 则是为了 debug。 -->
composer -vvv
<!-- --help (-h): 显示帮助信息。 -->
composer -h
--quiet (-q): 禁止输出任何信息。
--no-interaction (-n): 不要询问任何交互问题。
--working-dir (-d):
如果指定的话，使用给定的目录作为工作目录。
<!-- --profile: 显示时间和内存使用信息。 -->
composer --profile
--ansi: 强制 ANSI 输出。
--no-ansi: 关闭 ANSI 输出。
--version (-V): 显示当前应用程序的版本信息。
##初始化 init
1 | composer init |
##安装 install
说明：
install 命令从当前目录读取 composer.json 文件，处理了依赖关系，并把其安装到 vendor 目录下1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
composer install
<!-- 参数 -->
--prefer-source: 下载包的方式有两种： source 和 dist。对于稳定版本 composer 将默认使用 dist 方式。而 source 表示版本控制源 。如果 --prefer-source 是被启用的，composer 将从 source 安装（如果有的话）。如果想要使用一个 bugfix 到你的项目，这是非常有用的。并且可以直接从本地的版本库直接获取依赖关系。
--prefer-dist: 与 --prefer-source 相反，composer 将尽可能的从 dist 获取，这将大幅度的加快在 build servers 上的安装。这也是一个回避 git 问题的途径，如果你不清楚如何正确的设置。
--dry-run: 如果你只是想演示而并非实际安装一个包，你可以运行 --dry-run 命令，它将模拟安装并显示将会发生什么。
--dev: 安装 require-dev 字段中列出的包（这是一个默认值）。
--no-dev:跳过 require-dev 字段中列出的包。
--no-scripts:跳过 composer.json 文件中定义的脚本。
--no-plugins: 关闭 plugins。
--no-progress: 移除进度信息，这可以避免一些不处理换行的终端或脚本出现混乱的显示。
--optimize-autoloader (-o): 转换 PSR-0/4 autoloading 到 classmap 可以获得更快的加载支持。特别是在生产环境下建议这么做，但由于运行需要一些时间，因此并没有作为默认值。
Tips：
如果当前目录下存在 composer.lock 文件，它会从此文件读取依赖版本，而不是根据 composer.json 文件去获取依赖。这确保了该库的每个使用者都能得到相同的依赖版本。
如果没有 composer.lock 文件，composer 将在处理完依赖关系后创建它。
update
1 | 为了获取依赖的最新版本，并且升级 composer.lock 文件，你应该使用 update 命令。 |
##全局执行 global1
2
3
4composer global require fabpot/php-cs-fixer:dev-master
<!-- 如要更新 使用-->
composer global update
##搜索命令 search
说明：
search 命令允许你为当前项目搜索依赖包，通常它只搜索 packagist.org 上的包，你可以简单的输入你的搜索条件。1
2
3
4composer search lavarel
参数：
--only-name (-N): 仅针对指定的名称搜索（完全匹配）。
##展示命令 show
说明：
列出所有可用的软件包1
2
3
4
5
6
7
8
9composer show
composer show monolog/monolog
php composer.phar show monolog/monolog 1.2.1
参数：
--installed (-i): 列出已安装的依赖包。
--platform (-p): 仅列出平台软件包（PHP 与它的扩展）。
--self (-s): 仅列出当前项目信息。
php 之 composer 库/资源包
##创建一个包
1 | { |
##标签的解释
对于每一个看起来像版本号的标签，都会相应的创建一个包的版本。它应该符合 ‘X.Y.Z’ 或者 ‘vX.Y.Z’ 的形式，-patch、-alpha、-beta 或 -RC 这些后缀是可选的。在后缀之后也可以再跟上一个数字。
下面是有效的标签名称的几个例子：1
2
3
4
5
61.0.0
v1.0.0
1.10.5-RC1
v4.4.4beta2
v2.0.0-alpha
v2.0.4-p1
注意： 即使你的标签带有前缀 v， 由于在需要 require 一个版本的约束时是不允许这种前缀的， 因此 v 将被省略（例如标签 V1.0.0 将创建 1.0.0 版本）
##分支
对于每一个分支，都会相应的创建一个包的开发版本。如果分支名看起来像一个版本号，那么将创建一个如同 {分支名}-dev 的包版本号。例如一个分支 2.0 将产生一个 2.0.x-dev 包版本（加入了 .x 是出于技术的原因，以确保它被识别为一个分支，而 2.0.x 的分支名称也是允许的，它同样会被转换为 2.0.x-dev）。如果分支名看起来不像一个版本号，它将会创建 dev-{分支名} 形式的版本号。例如 master 将产生一个 dev-master 的版本号。
下面是版本分支名称的一些示例：
1.x
1.0 (equals 1.0.x)
1.1.x
##锁文件
如果你愿意，可以在你的项目中提交 composer.lock 文件。他将帮助你的团队始终针对同一个依赖版本进行测试。任何时候，这个锁文件都只对于你的项目产生影响。
如果你不想提交锁文件，并且你正在使用 Git，那么请将它添加到 .gitignore 文件中。
##发布到 VCS（线上版本控制系统）
一旦你有一个包含 composer.json 文件的库存储在线上版本控制系统（例如：Git），你的库就可以被 Composer 所安装。在这个例子中，我们将 acme/hello-world 库发布在 GitHub 上的 github.com/username/hello-world 中。
现在测试这个 agoogle/testName 包，我们在本地创建一个新的项目。我们将它命名为 acme/blog。此博客将依赖 google/testName，而后者又依赖 monolog/monolog。我们可以在某处创建一个新的 blog 文件夹来完成它，并且需要包含 composer.json 文件：1
2
3
4
5
6{
"name": "myapp/blog",
"require": {
"google/testName": "dev-master"
}
}
在这个例子中 name 不是必须的，因为我们并不想将它发布为一个库。在这里为 composer.json 文件添加描述。
现在我们需要告诉我们的应用，在哪里可以找到 hello-world 的依赖。为此我们需要在 composer.json 中添加 repositories 来源申明：1
2
3
4
5
6
7
8
9
10
11
12{
"name": "acme/blog",
"repositories": [
{
"type": "vcs",
"url": "https://github.com/google/testName"
}
],
"require": {
"google/testName": "dev-master"
}
}
更多关于包的来源是如何工作的，以及还有什么其他的类型可供选择，请查看资源库。
这就是全部了。你现在可以使用 Composer 的 install 命令来安装你的依赖包了！
小结： 任何含有 composer.json 的 GIT、SVN、HG 存储库，都可以通过 require 字段指定“包来源”和“声明依赖”来添加到你的项目中。
##发布到 packagist
好的，你现在可以发布你的包了，但你不会希望你的用户每次都这样繁琐的指定包的来源。
你可能注意到了另一件事，我们并没有指定 monolog/monolog 的来源。它是怎么工作的？答案是 packagist。
Packagist 是 Composer 主要的一个包信息存储库，它默认是启用的。任何在 packagist 上发布的包都可以直接被 Composer 使用。就像 monolog 它被 发布在 packagist 上，我们可以直接使用它，而不必指定任何额外的来源信息。
如果我们想与世界分享我们的 testName，我们最好将它发布到 packagist 上。这样做是很容易的。
你只需要点击那个大大的 “Submit Package” 按钮并注册。接着提交你库的来源地址，此时 packagist 就开始了抓取。一旦完成，你的包将可以提供给任何人使用。
ok.完
php 之 composer 的用法
##composer.json：项目安装
要开始在你的项目中使用 Composer，你只需要一个 composer.json 文件。该文件包含了项目的依赖和其它的一些元数据。
##关于 require Key
组成部分：
1.包名称： monolog/monolog
2.包版本：1.0.*1
2
3
4
5{
"require": {
"monolog/monolog": "1.0.*"
}
}
##包名称
组成部分：
1.供应商名称: monolog
2.项目名称： monolog
如：meizu/mei 2 google/android
##包版本
确切的版本号：1.0.2 —你可以指定包的确切版本。
范围：>=1.0 >=1.0,<2.0 >=1.0,<1.1|>=1.2 —-有效的运算符：>、>=、<、<=、!=。
你可以定义多个范围，用逗号隔开，这将被视为一个逻辑AND处理。一个管道符号|将作为逻辑OR处理。
AND 的优先级高于 OR。
通配符：1.0.—你可以使用通配符来指定一种模式。1.0.*与>=1.0,<1.1是等效的。
赋值运算符：~1.2— ~1.2相当于>=1.2,<2.0
~波浪符运算符
~ 最好用例子来解释： ~1.2 相当于 >=1.2,<2.0，而 ~1.2.3 相当于 >=1.2.3,<1.3。正如你所看到的这对于遵循 语义化版本号 的项目最有用。一个常见的用法是标记你所依赖的最低版本，像 ~1.2 （允许1.2以上的任何版本，但不包括2.0）。由于理论上直到2.0应该都没有向后兼容性问题，所以效果很好。你还会看到它的另一种用法，使用 ~ 指定最低版本，但允许版本号的最后一位数字上升。
注意： 虽然 2.0-beta.1 严格地说是早于 2.0，但是，根据版本约束条件， 例如 ~1.2 却不会安装这个版本。就像前面所讲的 ~1.2 只意味着 .2 部分可以改变，但是 1. 部分是固定的。
composer.lock - 锁文件 使用install 会自动生成
在安装依赖后，Composer 将把安装时确切的版本号列表写入 composer.lock 文件。这将锁定改项目的特定版本。
请提交你应用程序的 composer.lock （包括 composer.json）到你的版本库中
这是非常重要的，因为 install 命令将会检查锁文件是否存在，如果存在，它将下载指定的版本（忽略 composer.json 文件中的定义）。
这意味着，任何人建立项目都将下载与指定版本完全相同的依赖。你的持续集成服务器、生产环境、你团队中的其他开发人员、每件事、每个人都使用相同的依赖，从而减轻潜在的错误对部署的影响。即使你独自开发项目，在六个月内重新安装项目时，你也可以放心的继续工作，即使从那时起你的依赖已经发布了许多新的版本。
如果不存在 composer.lock 文件，Composer 将读取 composer.json 并创建锁文件。
这意味着如果你的依赖更新了新的版本，你将不会获得任何更新。此时要更新你的依赖版本请使用 update 命令。这将获取最新匹配的版本（根据你的 composer.json 文件）并将新版本更新进锁文件。
如果只想安装或更新一个依赖，你可以白名单它们1
composer update monolog/monolog [...]
##Packagist
packagist 是 Composer 的主要资源库。 一个 Composer 的库基本上是一个包的源：记录了可以得到包的地方。Packagist 的目标是成为大家使用库资源的中央存储平台。这意味着你可以 require 那里的任何包。
当你访问 packagist 网站 (packagist.org)，你可以浏览和搜索资源包。
任何支持 Composer 的开源项目应该发布自己的包在 packagist 上。虽然并不一定要发布在 packagist 上来使用 Composer，但它使我们的编程生活更加轻松。
##自动加载
对于库的自动加载信息，Composer 生成了一个 vendor/autoload.php 文件。你可以简单的引入这个文件，你会得到一个免费的自动加载支持。
require ‘vendor/autoload.php’;
这使得你可以很容易的使用第三方代码。例如：如果你的项目依赖 monolog，你就可以像这样开始使用这个类库，并且他们将被自动加载。1
2
3
4$log = new Monolog\Logger('name');
$log->pushHandler(new Monolog\Handler\StreamHandler('app.log', Monolog\Logger::WARNING));
$log->addWarning('Foo');
你可以在 composer.json 的 autoload 字段中增加自己的 autoloader。1
2
3
4
5{
"autoload": {
"psr-4": {"Acme\\": "src/"}
}
}
Composer 将注册一个 PSR-4 autoloader 到 Acme 命名空间。
你可以定义一个从命名空间到目录的映射。此时 src 会在你项目的根目录，与 vendor 文件夹同级。例如 src/Foo.php 文件应该包含 Acme\Foo 类。
添加 autoload 字段后，你应该再次运行 install 命令来生成 vendor/autoload.php 文件。
引用这个文件也将返回 autoloader 的实例，你可以将包含调用的返回值存储在变量中，并添加更多的命名空间。这对于在一个测试套件中自动加载类文件是非常有用的，例如。1
2$loader = require 'vendor/autoload.php';
$loader->add('Acme\\Test\\', __DIR__);
除了 PSR-4 自动加载，classmap 也是支持的。这允许类被自动加载，即使不符合 PSR-0 规范。详细请查看 自动加载-参考。
注意： Composer 提供了自己的 autoloader。如果你不想使用它，你可以仅仅引入 vendor/composer/autoload_*.php 文件，它返回一个关联数组，你可以通过这个关联数组配置自己的 autoloader。
Sublime Text3 之 emmet
HTML 的生成 按tab键或 ctrl+e
生成HTML文档结构
1 | <!-- 1.命令：html:5 or ! --> |
1 | <!-- 2.命令：html:xt --> |
1 | <!-- 3.命令：html:4s or heml:xs --> |
1 | <!-- 4.命令 div p h1 span em input 直接tab 即可 --> |
1 | <!-- 5.生成带有 id 、class 的 HTML 标签: #为 id，. 为 class --> |
1 | <!-- 6.生成后代：> --> |
1 | <!-- 7.生成兄弟元素: + --> |
1 | <!-- 8.生成上级元素： ^ --> |
1 | <!-- 9.重复生成多个 * --> |
1 | <!-- 10.生成分组 () --> |
1 | <!-- 11.生成自定义属性 [] --> |
1 | <!-- 13.特定顺序递增 @N --> |
1 | <!-- 14.多位递增 $$$$ --> |
1 | <!-- 15.递减 @- --> |
1 | <!-- 15.特定递减 @-N --> |
1 | <!-- 16.申城文本 {} --> |
