composer如何创建一个不带vendor目录的压缩包

要创建不包含vendor目录的Composer压缩包，推荐使用git archive命令。该方法利用Git的版本控制机制，仅打包被跟踪的源代码文件，自动排除.gitignore中定义的vendor目录等忽略项，生成纯净的源码分发包，适合让接收方自行通过composer install安装依赖，实现高效、安全、标准化的项目分发。

要创建一个不包含vendor目录的Composer压缩包，直接使用composer archive命令通常无法实现，因为它默认会将已安装的依赖（即vendor目录）也打包进去。更实际的做法是，在打包前确保vendor目录不存在，或者利用版本控制工具（如Git）的归档功能，只打包代码仓库中的文件，从而自然地排除vendor目录。

解决方案

composer archive命令在设计上，主要是为了打包当前项目的完整快照，包括其所有依赖。这意味着，如果你在项目根目录下运行composer install后，再执行composer archive，vendor目录自然会被包含进去。如果你真的想得到一个不带vendor目录的压缩包，核心思路就是确保在打包动作发生时，vendor目录不存在，或者利用其他工具的过滤能力。

最直接且推荐的方法，特别是当你的项目受版本控制（如Git）时，是利用版本控制系统的归档功能。

使用Git归档（推荐）： 如果你的项目是一个Git仓库，并且.gitignore文件中已经正确地忽略了vendor目录，那么你可以直接使用git archive命令。这个命令只会打包Git仓库中被跟踪的文件，自然会排除掉.gitignore中定义的忽略文件和目录，包括vendor。

示例命令：

git archive --format=zip --output=my-project-source.zip HEAD

这条命令会从当前HEAD创建一个名为my-project-source.zip的ZIP压缩包，其中只包含Git跟踪的文件，vendor目录不会被包含。这是分发项目源代码，让接收方自行运行composer install的最佳实践。

在没有vendor目录的情况下打包（局限性）： 如果你在项目当前没有vendor目录（比如刚克隆下来，还没运行composer install），此时运行composer archive，它就不会包含vendor。但这种场景下，composer archive通常会报错，因为它需要解析composer.json中的依赖，而这通常意味着需要vendor目录。所以，这个方法对于分发“可直接运行”的项目来说，并不实用。

因此，我个人认为，更合理的做法是：如果你要分发一个“干净的源代码包”，请使用git archive。如果你需要一个包含所有依赖但又不包含vendor的“部署包”（这通常意味着你已经打包了编译后的资产，并且vendor目录已经被处理或不必要），那么你的打包流程需要更复杂，可能涉及先删除vendor，再进行打包。但这种情况，通常会通过Docker镜像或者其他部署工具来管理，而不是简单的composer archive。

为什么composer archive会包含vendor目录？

composer archive命令的设计初衷，是为了生成一个当前项目状态的完整快照，这包括了所有已安装的依赖包。当你在项目根目录执行composer install后，vendor目录就成为了项目运行环境不可或缺的一部分。composer archive在执行时，会扫描并打包当前工作目录下的所有文件和文件夹，除非这些文件被.gitattributes或.gitignore（在某些特定配置下）明确排除，但对于vendor目录，它通常被视为项目的一部分而被包含。

从开发者的角度看，composer archive更像是为“部署准备”而非“源代码分发”而生。如果你希望将一个应用程序部署到生产环境，并且希望它能立即运行，那么包含vendor目录是合理的。这样接收方就不需要再次运行composer install，省去了部署步骤。但如果你只是想分享项目的原始代码，让其他人自行管理依赖，那么composer archive的这种行为就显得有些“过度打包”了。

这种设计哲学体现了Composer在管理项目依赖方面的核心作用：它不仅是下载工具，更是项目环境的定义者。一个完整的Composer项目，在运行时，往往需要vendor目录中的类库支持。所以，将vendor目录一同打包，是符合其“完整项目快照”这一理念的。

除了git archive，还有哪些方法可以实现不带vendor的打包？

当然，除了利用Git的版本控制能力，我们还有一些其他方法来达成目的，虽然这些方法可能在自动化程度或便捷性上略逊一筹，但在特定场景下依然有用。

PhotoAid Image Upscaler

PhotoAid出品的免费在线AI图片放大工具

52

查看详情

手动清理与打包： 这是最直接但最不推荐自动化的方式。你可以在打包前手动删除vendor目录，然后使用操作系统自带的压缩工具（如zip命令或文件管理器）对项目进行压缩。

# 假设你在项目根目录
rm -rf vendor
zip -r my-project-no-vendor.zip ./*
# 打包完成后，如果你还需要vendor目录，需要重新安装
composer install

这种方法简单粗暴，但缺点显而易见：你需要记住在打包前执行rm -rf vendor，并且在打包后如果需要继续开发，还需要composer install，这很容易出错或遗忘。

自定义脚本打包： 为了避免手动操作的繁琐和风险，你可以编写一个简单的脚本来自动化这个过程。这个脚本可以负责：

1. 创建一个临时目录。
2. 将项目中的核心文件（除了vendor和.git等）复制到临时目录。
3. 对临时目录进行压缩。
4. 清理临时目录。

例如，一个简单的Bash脚本片段：

#!/bin/bash

PROJECT_NAME="my-awesome-project"
TEMP_DIR="/tmp/${PROJECT_NAME}_package"
OUTPUT_FILE="${PROJECT_NAME}-source.zip"

echo "Creating temporary directory: ${TEMP_DIR}"
mkdir -p "${TEMP_DIR}"

echo "Copying project files (excluding vendor and .git)..."
# 注意：这里需要根据你的项目结构和需要排除的文件进行调整
# rsync是一个非常强大的工具，可以精确控制包含和排除
rsync -a --exclude 'vendor/' --exclude '.git/' --exclude '.idea/' --exclude 'node_modules/' . "${TEMP_DIR}/"

echo "Creating zip archive: ${OUTPUT_FILE}"
cd "${TEMP_DIR}"
zip -r "../../${OUTPUT_FILE}" ./*
cd - # 返回原来的目录

echo "Cleaning up temporary directory: ${TEMP_DIR}"
rm -rf "${TEMP_DIR}"

echo "Package created successfully: ${OUTPUT_FILE}"

这种方法提供了高度的灵活性和控制力，你可以根据项目的具体需求来定制排除规则。它比手动操作更健壮，也更适合集成到CI/CD流程中。

.gitattributes与export-ignore（针对git archive的补充说明）： 虽然前面提到了git archive，但值得一提的是，.gitattributes文件中的export-ignore属性可以让你更精细地控制git archive的行为。如果你想在Git仓库中跟踪vendor目录（尽管这通常不推荐），但又希望git archive在打包时排除它，就可以在.gitattributes中添加：

vendor/ export-ignore

这会告诉git archive在创建归档时忽略vendor目录。这是一种非常优雅且强大的方式，前提是你的项目在Git版本控制之下。

分发不带vendor目录的压缩包有什么好处和注意事项？

分发不带vendor目录的压缩包，是许多项目，尤其是开源项目和库的推荐做法。这背后有其充分的理由，但同时也有一些需要注意的地方。

好处：

1. 包体更小，传输更快： vendor目录往往是项目中最庞大的一部分，包含了所有第三方依赖。排除它能显著减小压缩包的体积，从而加快下载和传输速度，也节省存储空间。
2. 源代码更纯净： 接收方拿到的是项目的纯粹源代码，不包含任何外部依赖的二进制文件或缓存。这对于代码审查、理解项目结构非常有帮助。
3. 强制依赖管理： 接收方必须自行运行composer install（或composer update），这意味着他们会根据composer.json和composer.lock（如果存在）来安装依赖。这确保了依赖是最新的，或者至少是项目作者所期望的精确版本，避免了因依赖版本不一致导致的问题。
4. 避免安全风险： 预打包的vendor目录可能包含过时的、存在已知安全漏洞的依赖。让接收方自行安装，可以确保他们获取到的是最新、最安全的依赖版本。
5. 更好的版本控制实践： 将vendor目录排除在版本控制之外（通过.gitignore），可以保持仓库的精简，避免大量不必要的二进制文件提交，从而加速Git操作（克隆、拉取、推送）。
6. 适应不同环境： 不同的部署环境可能有不同的PHP版本或扩展要求，让接收方自行安装依赖，可以更好地适应其特定的运行环境。

注意事项：

1. 接收方需要Composer环境： 显而易见，接收方必须安装Composer，并且知道如何运行composer install命令。这对于非技术用户来说可能是一个门槛。
2. 需要网络连接： 运行composer install需要从Packagist等源下载依赖包，这意味着接收方的机器需要有可用的互联网连接。
3. 依赖锁定文件的重要性： 如果你希望接收方安装的依赖版本与你开发时保持一致，那么务必在项目中包含composer.lock文件并将其纳入版本控制。composer.lock会精确锁定每个依赖的版本，确保在不同机器上安装的依赖环境一致性。如果没有composer.lock，composer install可能会安装最新兼容版本，这可能导致意想不到的行为。
4. 首次安装时间： 第一次运行composer install可能会花费一些时间，特别是当依赖数量庞大时。
5. 部署流程的考虑： 在CI/CD或自动化部署流程中，你需要确保在部署脚本中包含了composer install --no-dev --optimize-autoloader这样的步骤，以确保生产环境的依赖安装正确且高效。

总的来说，分发不带vendor目录的压缩包是现代PHP项目管理的标准实践，它强调了依赖管理的责任转移和环境的独立性，但要求接收方具备一定的技术能力和环境准备。

以上就是composer如何创建一个不带vendor目录的压缩包的详细内容，更多请关注php中文网其它相关文章！