알아야 할 Composer 버전 제약 조건

아직 작곡가를 모르신다면 컴포저 사용법 튜토리얼 칼럼으로 가셔서 읽어보세요.

저는 자신이 사용하는 작성기 패키지 간의 종속성 제약으로 인해 어려움을 겪는 사람들을 많이 보았습니다. 이 기사가 일부 문제의 원인을 지적하고 이를 방지하는 방법을 제공할 수 있기를 바랍니다. 최악의 시나리오부터 시작하여 제약 조건을 단계별로 개선하겠습니다.

The Almighty Star: **

Composer 有一个依赖解析器，所以它能够自动的找出我想要的，对吗？错。

用 * 声明一个版本约束可能是最糟糕的做法之一。因为你绝对无法控制你会得到什么。它可能是 任何 匹配 minimum-stability 和其它约束的版本。

基本上你就相当于在和 Composer 玩一个 俄罗斯轮盘赌 游戏，最终你会被它伤害到。然后你就可能会责怪这个工具太令你失望了。

如果你继续粗心大意，请最起码依赖最新的开发版本，通常被标记为 dev-master。

写死的分支名称

所以你现在在使用 dev-master。问题在于，dev-master 所指向的代码可能会更改。至少，你获取的总是不稳定的包（从 composer 所表征的稳定性标志来看不稳定）。然而，更大的问题在于，dev-master 的意义可能随时会变。

比方说，现在它所表示的是最新的 1.0 开发版本。当开发者说他们要开始开发 1.1 版本的时候，dev-master 这个分支名字不再指向 1.0 分支，它开始指向最新的 1.1 开发分支。

除非你紧密关注着该库的开发，否则，直到你运行了 composer update 命令时，问题才会显示在你面前，然后毁了你一整天。因此，直接引用分支的名称并不是一个可持续的解决方案。幸运的是，在别名的问题上，composer 可以提供帮助。

分支别名

分支别名作为一个属性，包维护者可以将其放到他们的 composer.json 里面，允许这些分支名称映射到版本上。

像 1.0 ， 2.1 等等分支名称并不是必须的， Composer 已经对这些进行了处理。

但是像 master 这样的分支名称会产生一个名为 dev-master 的版本，你一定要给它别名。 Composer 文档里面有 一个不错的关于别名的文章 ，里面解释了如何定义分支别名：

{
    "extra": {
        "branch-alias": {
            "dev-master": "1.0.x-dev"
        }
    }
}

dev-master 版本会映射到一个 1.0.x-dev 的别名上，

这基本上意味着你可以用一个 1.0.*@dev 的约束来要求包。这样的好处是 1.0 的含义会被定义，且不会改变。 它也将使切换到稳定版本更容易。

分支别名的警告需要包维护者将它们放入。如果使用的是没有分支别名的库，则向它们发送一个上拉请求，将上面的 extra 部分添加到它们的 composer.json 中。

稳定版本

1.0.*@dev

🎜Composer에는 종속성 파서가 있어서 내가 원하는 것이 무엇인지 자동으로 파악할 수 있죠? 잘못된. 🎜🎜* 를 사용하여 버전 제약 조건을 선언하는 것은 아마도 최악의 관행 중 하나일 것입니다. 왜냐하면 당신은 당신이 얻는 것에 대해 전혀 통제할 수 없기 때문입니다. 최소 안정성 및 기타 제약 조건과 일치하는 모든 버전일 수 있습니다. 🎜🎜기본적으로 Composer로 러시안 룰렛 게임을 하고 있는데 결국에는 다치게 될 것입니다. 그러면 당신을 실망시킨 도구를 탓할 수도 있습니다. 🎜🎜계속 부주의하다면 적어도 일반적으로 dev-master 태그가 붙은 최신 개발 버전을 사용하시기 바랍니다. 🎜🎜🎜Hardwired 지점 이름🎜🎜🎜그래서 이제 dev-master를 사용하고 있습니다. 문제는 dev-master가 가리키는 코드가 변경될 수 있다는 것입니다. 적어도 얻을 수 있는 것은 항상 불안정한 패키지입니다(작곡가가 나타내는 안정성 플래그에 따라 불안정함). 그러나 더 큰 문제는 dev-master의 의미가 언제든지 바뀔 수 있다는 것입니다. 🎜🎜예를 들어 이제는 최신 1.0 개발 버전을 나타냅니다. 개발자가 버전 1.1 개발을 시작하겠다고 말하면 dev-master 라는 브랜치 이름은 더 이상 1.0 브랜치를 가리키지 않고 최신 1.1 개발 브랜치를 가리키기 시작합니다. 🎜🎜이 라이브러리의 개발을 면밀히 따르지 않으면 작곡가 업데이트 명령을 실행하기 전까지 문제가 눈앞에 나타나서 하루를 망치게 될 것입니다. 따라서 지점 이름을 직접 참조하는 것은 지속 가능한 솔루션이 아닙니다. 다행히 앨리어싱과 관련하여 composer가 도움을 줄 수 있습니다. 🎜🎜🎜Branch Alias🎜🎜🎜Branch Alias는 패키지 관리자가 작곡가.json 에 넣어 이러한 분기 이름을 버전에 매핑할 수 있는 속성입니다. 🎜🎜1.0, 2.1 등과 같은 분기 이름은 필수가 아니며 Composer 에서 이미 처리했습니다. 🎜🎜그러나 master 와 같은 브랜치 이름은 dev-master 라는 버전을 생성하므로 별칭을 지정해야 합니다. Composer 문서에는 분기 별칭을 정의하는 방법을 설명하는 별칭에 대한 유용한 기사가 있습니다. 🎜rrreee🎜 dev-master 버전은 1.0에 매핑됩니다. x-dev 의 별칭, 🎜🎜이는 기본적으로 1.0.*@dev 제약 조건이 있는 패키지가 필요할 수 있음을 의미합니다. 이것의 장점은 1.0의 의미가 정의되고 변경되지 않는다는 것입니다. 또한 안정적인 릴리스로의 전환도 더 쉬워집니다. 🎜🎜브랜치 별칭에 대한 경고는 패키지 관리자가 이를 넣어야 합니다. 분기 별칭 없이 라이브러리를 사용하는 경우 위의 extra 섹션을 composer.json에 추가하여 풀 요청을 보냅니다. 🎜🎜🎜안정 버전🎜🎜🎜1.0.*@dev 이 제약 조건은 이미 매우 좋습니다. 하지만 문제는 아직까지 안정적인 버전이 없다는 점이다. 여전히 불안정한 버전을 실행하고 있다는 사실 외에는 코드에 아무런 문제가 없습니다. 🎜

그러나 다른 사람의 프로젝트가 귀하의 패키지에 의존하는 경우 사용자는 명시적으로 @dev 플래그를 사용하여 Composer가 불안정한 버전을 설치할 수 있도록 허용하거나 프로젝트의 최소 안정성을 줄여야 합니다. code>는 모든 종속 패키지의 불안정한 버전을 얻게 됨을 의미합니다. @dev 标识来允许 Composer 安装不稳定的版本，或者干脆降低项目 minimum-stability 的等级，这意味着他们将获得 所有依赖包 的不稳定版本。

避免开发版本不稳定性的最好方法就是打上 release 标签（指发布稳定版本）。 如果你正在使用一个没有打上 release 标签的库，提醒它的维护者直到打上标签。现在就做！

作为 Composer 社区的一份子，我们要有责任心。 我们必须发布稳定的版本，并且应该维护好 CHANGELOG （更新日志）。 这很不容易，但是这将让整个生态系统发生巨大的改变。记住，如实地、 语义化 地来打标签。

当你发布了一个稳定的版本，你就能去掉 @dev 标识并且将你的约束改为 1.0.* 。

下一个重大版本

如果你所依赖的包的每一个发布节点都坚持遵守语义化版本的规则，并且严格向后兼容，那么你就可以逐渐提高约束。

现在 1.0.* 版本有一些潜在的兼容性问题，并很快发布了 1.1 版本。如果你的约束是 1.0 ，但是别人需要 1.1 版本的新特性（还记得向后兼容吗？）， 他们就不能安装 1.1 版本。所以你需要重写你的约束，比如： 1.* 。

好极了，除非你开始依赖 1.1 版本的新特性，否则你不必修改约束，它将会仍然匹配 1.0 这个没有新特性的版本。

接着，你修改约束为 >=1.1,，但这种写法比较麻烦。使用波浪线操作符能允许你用简洁的方式表示上面的表达式：<code> ~1.1 。这表示任意在 1.1 以上的 1.* 版本。现在你知道了，鼓励语义化版本是为了使用波浪线操作符，并且可以最大化的封装兼容性。

TLDR

使用 branch-alias。

标签发布，使发布更可靠和 符合语义.

使用 ~

개발 버전의 불안정성을 방지하는 가장 좋은 방법은 릴리스 태그(안정 버전 릴리스를 의미)를 붙이는 것입니다. release 태그가 지정되지 않은 라이브러리를 사용하는 경우 태그가 지정될 때까지 관리자에게 알립니다. 지금 해보세요! 🎜🎜Composer 커뮤니티의 일원으로서 우리는 책임을 져야 합니다. 우리는 안정적인 버전을 출시해야 하며 CHANGELOG(변경 로그)를 유지해야 합니다. 쉽지는 않겠지만 생태계 전체에 큰 변화를 가져올 것입니다. 진실하고 의미 있게 라벨을 지정하는 것을 잊지 마세요. 🎜🎜안정적인 버전을 출시할 때 @dev 태그를 제거하고 제약 조건을 1.0.*로 변경할 수 있습니다. 🎜🎜다음 주요 버전🎜🎜 의존하는 패키지의 모든 릴리스 노드가 의미 체계 버전 관리 규칙을 준수하고 이전 버전과 엄격하게 호환되는 경우 제약 조건을 점진적으로 늘릴 수 있습니다. 🎜🎜현재 1.0.* 버전에는 일부 잠재적인 호환성 문제가 있으며, 1.1 버전이 곧 출시될 예정입니다. 제약 조건이 1.0인데 다른 사람이 1.1의 새로운 기능이 필요한 경우(이전 버전과의 호환성을 기억하시나요?) 1.1를 설치할 수 없습니다. 버전. 따라서 1.*와 같은 제약 조건을 다시 작성해야 합니다. 🎜🎜좋습니다. 1.1 버전의 새로운 기능을 사용하지 않는 한 제약 조건을 변경할 필요가 없으며 새로운 기능이 없는 1.0 과 계속 일치합니다. . 🎜🎜다음으로 제약 조건을 >=1.1,으로 수정하지만 이 작성 방식이 더 번거롭습니다. 물결표 연산자를 사용하면 위의 표현식을 <code> ~1.1 처럼 간결하게 표현할 수 있습니다. 이는 1.1 이상의 1.* 버전을 의미합니다. 이제 의미론적 버전에서 물결표 연산자를 사용하고 패키지 호환성을 최대화하는 것이 권장된다는 것을 알았습니다. 🎜🎜TLDR🎜🎜 분기 별칭을 사용하세요. 🎜🎜게시를 더욱 안정적이고 의미 있게 만들기 위한 태그 게시 🎜🎜 ~ 연산자를 사용하세요. 🎜

위 내용은 알아야 할 Composer 버전 제약 조건의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!