auth.json文件的作用

auth.json 是 Composer(PHP 的依赖管理工具)在某些情况下生成的私有包认证配置文件。

使用场景
当你的项目需要从私有 Composer 仓库(如公司内部的 Packagist、私有 Git 仓库、Satis、Toran Proxy、Artifactory 等)安装包时,Composer 会要求你提供认证信息(用户名/密码、token、SSH 密钥等)。

为了避免每次 composer update/install 都手动输入凭证,Composer 会把这些认证信息保存到项目根目录下的 auth.json 文件中。

内容示例

{
    "http-basic": {
        "packages.example.com": {
            "username": "my-company-user",
            "password": "super-secret-token-123456"
        }
    },
    "github-oauth": {
        "github.com": "ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    },
    "gitlab-token": {
        "gitlab.example.com": "glpat-xxxxxxxxxxxxxxxxxxxx"
    }
}

存放位置
项目根目录(和 composer.json 同级)。有时也会出现在用户全局目录:~/.composer/auth.json(旧版 Composer)或 ~/.config/composer/auth.json(新版)

是否需要提交到 Git?
绝对不要提交!必须忽略。因为里面包含明文凭证(用户名、密码、token),提交到 Git 仓库会导致严重的安全泄露(任何人拉代码都能看到你的私有仓库凭证)。并且不同开发者的凭证不同,提交后会互相冲突

如何正确管理 auth.json?
1 个人开发机:让 Composer 自动生成(运行 composer config –auth … 时会创建)
2 CI/CD 环境(GitHub Actions、GitLab CI、Jenkins 等):不要提交文件,而是通过环境变量注入凭证,例如:

composer config --auth http-basic.packages.example.com.username "${COMPOSER_USERNAME}"
composer config --auth http-basic.packages.example.com.password "${COMPOSER_PASSWORD}"


或使用 COMPOSER_AUTH 环境变量(JSON 字符串):

export COMPOSER_AUTH='{"http-basic":{"packages.example.com":{"username":"xxx","password":"yyy"}}}'

3 团队协作:把认证信息写到 .env 或 CI 变量中,项目中只保留 auth.json.example(空模板)。

安装中文语言包composer require “overtrue/laravel-lang:~6.0″后,在浏览器刷新页面报错Call to undefined method Illuminate\Translation\FileLoader::loadPath()

我的Laravel版本是10,报错原因是overtrue/laravel-lang:~6.0与Laravel 10不兼容,composer require “overtrue/laravel-lang”输出一条警告说:

Package overtrue/laravel-lang is abandoned, you should avoid using it.

在Laravel 10我们应该使用laravel-lang/lang语言包。因此这个报错的解决方法是,先移除overtrue/laravel-lang:~6.0包:

composer remove overtrue/laravel-lang

再安装laravel-lang/lang语言包:

composer require laravel-lang/lang

安装好了后,执行以下命令添加中文语言包到Laravel 10:

php artisan lang:add zh_CN

我们可以看到在resources/lang目录里增加了zh_CN.json文件和zh_CN文件夹。

然后修改config/app.php,找到’locale’ => ‘en’,改为’locale’ => ‘zh_CN’。

刷新浏览器看看。

更多laravel-lang/lang语言包的用法,例如如何添加多个语言包到Laravel、如何在“语言.json”文件里增加自定义的条目等,请查看laravel-lang/lang语言包的官方文档:Getting Started | Laravel Lang (laravel-lang.com)

参考

https://www.cnblogs.com/inkqx/p/13563856.html

composer安装Laravel 11报错:laravel/framework[v11.9.0, …, v11.23.3] require fruitcake/php-cors ^1.3 -> found fruitcake/php-cors[dev-feat-setOptions, dev-master, dev-maincomposer…

我在使用composer安装Laravel 11的时候,遇到如下错误:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - laravel/framework[v11.9.0, ..., v11.23.3] require fruitcake/php-cors ^1.3 -> found fruitcake/php-cors[dev-feat-setOptions, dev-master, dev-main, dev-test-8.2, v0.1.0, v0.1.1, v0.1.2, v1.0-alpha1, ..., 1.2.x-dev (alias of dev-master)] but it does not match the constraint.
    - Root composer.json requires laravel/framework ^11.9 -> satisfiable by laravel/framework[v11.9.0, ..., v11.23.3].

原因是阿里云composer镜像源中没有fruitcake/php-cors包的最新版。

解决方法是,切换回默认的composer镜像源:

composer config -g --unset repos.packagist

执行composer install就安装成功了,不再报错。

参考

https://github.com/laravel/framework/issues/51201

为什么PHP的Composer包管理使用vendor模式而非全局模式?

vendor模式即在每个项目都创建一个vendor目录,用来存储本项目依赖的第三方模块的包或库文件。

全局模式即在操作系统的某个全局目录(一般是用户家目录里的某个子目录或者操作系统的某个系统目录)里,存储第三方模块的包或库文件,可以被多个项目共用,优点是相对于vendor模式节省存储空间。

都说PHP项目上线速度快,最大原因是PHP项目可以热更新热部署,通过FTP把整个PHP项目的源代码文件上传到服务器就部署好了,都不用重启Web服务器软件的。但是如果使用全局模式就会破坏这种方便的部署方式,因为你把PHP项目的源代码文件上传到服务器后,要么你还要把全局目录上传到服务器,要么你还需要在服务器运行composer命令安装本项目所缺的依赖项。使用vendor模式,就没有这个烦恼了。

Composer包管理器使用vendor模式,而非全局模式,应该就是出于这点考虑。像Go的go get、Java的maven、Node.js的npm、Python的pip使用全局模式,是因为它们无法做到像PHP那样热更新热部署Web项目。