要创建不包含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的版本控制能力，我们还有一些其他方法来达成目的，虽然这些方法可能在自动化程度或便捷性上略逊一筹，但在特定场景下依然有用。
一帧秒创
基于秒创AIGC引擎的AI内容生成平台，图文转视频，无需剪辑，一键成片，零门槛创作视频。
41 查看详情
手动清理与打包：这是最直接但最不推荐自动化的方式。你可以在打包前手动删除vendor目录，然后使用操作系统自带的压缩工具（如zip命令或文件管理器）对项目进行压缩。
# 假设你在项目根目录rm -rf vendorzip -r my-project-no-vendor.zip ./*# 打包完成后，如果你还需要vendor目录，需要重新安装composer install
这种方法简单粗暴，但缺点显而易见：你需要记住在打包前执行rm -rf vendor，并且在打包后如果需要继续开发，还需要composer install，这很容易出错或遗忘。
自定义脚本打包：为了避免手动操作的繁琐和风险，你可以编写一个简单的脚本来自动化这个过程。这个脚本可以负责：
创建一个临时目录。将项目中的核心文件（除了vendor和.git等）复制到临时目录。对临时目录进行压缩。清理临时目录。
例如，一个简单的Bash脚本片段：
#!/bin/bashPROJECT_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目录的压缩包，是许多项目，尤其是开源项目和库的推荐做法。这背后有其充分的理由，但同时也有一些需要注意的地方。
好处：
包体更小，传输更快： vendor目录往往是项目中最庞大的一部分，包含了所有第三方依赖。排除它能显著减小压缩包的体积，从而加快下载和传输速度，也节省存储空间。源代码更纯净： 接收方拿到的是项目的纯粹源代码，不包含任何外部依赖的二进制文件或缓存。这对于代码审查、理解项目结构非常有帮助。强制依赖管理： 接收方必须自行运行composer install（或composer update），这意味着他们会根据composer.json和composer.lock（如果存在）来安装依赖。这确保了依赖是最新的，或者至少是项目作者所期望的精确版本，避免了因依赖版本不一致导致的问题。避免安全风险： 预打包的vendor目录可能包含过时的、存在已知安全漏洞的依赖。让接收方自行安装，可以确保他们获取到的是最新、最安全的依赖版本。更好的版本控制实践： 将vendor目录排除在版本控制之外（通过.gitignore），可以保持仓库的精简，避免大量不必要的二进制文件提交，从而加速Git操作（克隆、拉取、推送）。适应不同环境： 不同的部署环境可能有不同的PHP版本或扩展要求，让接收方自行安装依赖，可以更好地适应其特定的运行环境。
注意事项：
接收方需要Composer环境： 显而易见，接收方必须安装Composer，并且知道如何运行composer install命令。这对于非技术用户来说可能是一个门槛。需要网络连接： 运行composer install需要从Packagist等源下载依赖包，这意味着接收方的机器需要有可用的互联网连接。依赖锁定文件的重要性： 如果你希望接收方安装的依赖版本与你开发时保持一致，那么务必在项目中包含composer.lock文件并将其纳入版本控制。composer.lock会精确锁定每个依赖的版本，确保在不同机器上安装的依赖环境一致性。如果没有composer.lock，composer install可能会安装最新兼容版本，这可能导致意想不到的行为。首次安装时间： 第一次运行composer install可能会花费一些时间，特别是当依赖数量庞大时。部署流程的考虑： 在CI/CD或自动化部署流程中，你需要确保在部署脚本中包含了composer install --no-dev --optimize-autoloader这样的步骤，以确保生产环境的依赖安装正确且高效。
总的来说，分发不带vendor目录的压缩包是现代PHP项目管理的标准实践，它强调了依赖管理的责任转移和环境的独立性，但要求接收方具备一定的技术能力和环境准备。
以上就是composer如何创建一个不带vendor目录的压缩包的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/254676.html
微信扫一扫 
支付宝扫一扫 
