IT이야기

Composer 패키지를 개발하고 포함하는 방법

cyworld 2021. 10. 16. 10:41
반응형

Composer 패키지를 개발하고 포함하는 방법은 무엇입니까?


PHP로 패키지를 개발하고 싶지만 GitHub 또는 어딘가에서 즉시 사용할 수 있기를 원하지 않습니다. 내 에 Packagist 파일을 포함하는 것은 쉽지만 composer.json로컬 패키지를 내 composer.json? 또한 /vendor/foo/bar( root 에 상대적인) 패키지를 빌드해야 합니까 composer.json, 아니면 다른 위치에 넣어야 합니까?

편집 : 내 질문은 다른 사람들이 패키지를 작성하는 방법에 관한 것 같습니다. 모든 새 패키지가 Packagist에 추가되고 변경 사항을 테스트하고 싶을 때 GitHub(또는 어디에서든)에 커밋한 다음 Composer를 통해 다시 풀다운합니까? 정말 비효율적인 것 같습니다.


이 질문에는 설명해야 할 다양한 구성 요소/표준이 있으므로 여기에서 가능한 한 많이 설명하려고 노력할 것이며 더 구체적인 질문이 나오면 저에게 PM을 보내거나 Google에 문의할 수 있습니다.

첫 번째 질문인 "로컬 패키지를 내 composer.json?"에 어떻게 추가 합니까?

"로컬 패키지 추가"가 클래스/패키지를 자동 로드하는 것을 의미하는 경우 작곡가에서 PSR-4 또는 PSR-0 또는 클래스맵 옵션을 사용하여 이를 수행할 수 있습니다.

더 읽기

PSR-0, PSR-4 및 Classmap에 대한 추가 정보가 필요한 경우 Google에서 검색할 수 있습니다.

예시

"autoload": {
   "psr-4": { "Core\\": "src/Core" }  ## "standard": { "namespace" : "path/to/dir"}
}

또는 (편집)

실제로 로컬 패키지를 추가하려면:

  1. 다음 composer.json과 같이 로컬 패키지를 만듭니다 .

    {
       "name": "localPackage/core",
       "version": "dev-master"
    }
    

    필요에 따라 다른 속성 및/또는 종속성을 지정할 수도 있습니다.

  2. composer.json파일을 루트 파일로 하여 패키지를 압축하고 archive.zip원하는 위치에 배치합니다.

  3. 로컬 패키지를 포함하려는 다른 프로젝트/패키지에서 다음과 같이 필수 매개변수에 로컬 패키지 이름을 추가합니다.

    "localPackage/core": "dev-master"
    

    repositories매개변수 아래에 다음을 추가합니다 .

    "repositories" : [
        {
            "type": "artifact",
            "url": "path/to/localPackage.zip"
        }
    ]
    

이제 git에 로컬 패키지가 있는 경우 패키지를 보관할 필요가 없으며(기본적으로 2단계 생략) 위의 예에서 URL을 path/to/localPackage/.git.

(편집 끝)


이제 더 큰 질문에 대답해 보겠습니다. "Composer 패키지를 어떻게 개발하고 포함합니까?":

  1. 디렉토리 구조를 결정하십시오. 일반적으로 다음과 같습니다.

    /PackageRoot
        /src/PackageCore
        composer.json   ## this is your library’s composer.json
        LICENSE
    

    설정하고 composer.json.

    광산 composer.json파일 중 하나의 예는 http://pastebin.com/tyHT01Xg 에서 찾을 수 있습니다 .

  2. 에 업로드 Github에서버전에 태그를 . 시맨틱 버전 관리를 사용합니다 ( vendorGithub에 업로드할 때 디렉터리 를 제외/무시해야 함 ).

  3. Packagist에 패키지를 등록합니다 (로그인 후).

    커밋에 v1.0.0(또는 이와 유사한) 태그를 지정하면 해당 패키지의 Packagist 대시보드에 표시됩니다.

이제 모든 것이 올바르게 완료되면 해당 프로젝트에 라이브러리를 추가하여 다른 프로젝트의 종속성으로 라이브러리를 사용할 수 있어야 합니다 composer.json.


새 리포지토리를 만드는 대신 작성기에 로컬 경로를 사용하도록 지시할 수 있습니다.

https://getcomposer.org/doc/05-repositories.md#path

예를 들어 다음 아래에 PHP 프로젝트가 있다고 가정해 보겠습니다. ~/devel/projects

에 기본 프로젝트가 ~/devel/projects/main_project있고 에 "로컬 패키지"가 있을 수 있습니다.~/devel/projects/local_package

로컬 패키지에 대한 작성기 구성을 정의하십시오. 에서 ~/devel/projects/local_package/composer.json.

{
    "name": "your_vendor_id/your_local_package",
    ...
}

그런 다음 ~/devel/projects/main_project/composer.json경로 저장소를 통해 로컬 패키지를 편집 하고 연결할 수 있습니다.

"repositories": [
    {
        "type": "path",
        "url": "../local_package",
        "options": {
            "symlink": true
        }
    }
],
"require": {
    "your_vendor_id/your_local_package": "dev-master",
    ...
}

이 링크에 대한 추가 정보(내가 작성한 것은 아니지만 이 주제에 대한 좋은 설명이 있음):

https://carlosbuenosvinos.com/working-at-the-same-time-in-a-project-and-its-dependencies-composer-and-path-type-repository/


이 스레드에 대한 대부분의 답변은 "알고 있지" 않은 것 같습니다. 나는 Composer를 처음 사용하지만 이러한 답변은 오해의 소지가 있습니다. 질문은 간단히 "작곡자 패키지를 개발할 수 있는 방법"이라고 할 수 있습니다.

예, 사용자 지정 리포지토리를 사용하거나 미완성 패키지를 업로드하고 모든 변경 후에 업데이트할 수 있습니다. 그 어느 쪽도 올바른 해결책이나 질문에 대한 답이 아닙니다.

Composer의 공식 문서에 이를 미리 명시 하지 않은 것은 도움이 되지 않지만 Libraries 문서 페이지 에서 제목을 볼 수 있습니다 .

모든 프로젝트는 패키지입니다

이것은 이해하는 것이 매우 중요합니다

작곡가.json:

이전에 언급한 페이지는 다음과 같이 계속됩니다.

해당 패키지를 설치 가능하게 만들려면 이름을 지정해야 합니다. name 속성을 추가하여 이 작업을 수행합니다.composer.json

{
    "name": "acme/hello-world",
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

지금까지 이 예제에서는 필수 패키지가 있고 이제 이름이 있습니다. vendor/name형식에 유의하십시오 .

이제 기본 사용 페이지 에 설명된 자체 파일을 자동 로드 합니다.

{
    "autoload": {
        "psr-4": {"Acme\\": "src/"}
    }
}

그러면 src/Acme디렉토리 아래에 네임스페이스가 지정된 클래스 파일이 자동으로 로드됩니다 .

재미에.

업데이트를 설치하다

다음 명령을 사용하여 패키지를 설치하거나 업데이트합니다.

composer update

또는

php composer.phar update

그러면 필요한 패키지가 다운로드되고 autoload.php 파일이 생성됩니다.

프로젝트 구조는 다음과 유사해야 합니다.

src
    Acme
        Foo.php
vendor
    monolog
        ...
composer.json

포함

이제 테스트합니다.

autoload.php 포함

require_once 'path/to/project/vendor/autoload.php';

Foo.php가 다음과 같다고 가정합니다.

<?php

namespace Acme;

class Foo {
    public static function bar(){
        return 'baz';
    }
}

?>

그런 다음 스크립트에서 이것을 호출할 수 있습니다.

echo Acme\Foo::bar(); // baz

제가 언급했을 수 있는 잘못된 정보를 수정하십시오. 이것이 대중적인 질문에 대한 해결책인 것 같습니다.


다음은 솔루션과 내 솔루션에 대한 요약입니다.

  1. 패키지에 게시

아직 게시하고 싶지 않기 때문에 개발 중이므로 이는 좋지 않은 옵션입니다.

  1. 깃허브 업로드

라이브러리 소스를 github에 게시하고 싶지 않거나 개인 저장소에 대한 비용을 지불하고 싶지 않거나 클라우드 외부 서비스를 사용하지 못할 수 있습니다(정치 또는 네트워크 정책으로 인해).

  1. 라이브러리 압축

예제 구현에서 작성기 리포지토리 경로를 사용하여 로컬 zip 파일을 릴리스로 가리킬 수 있습니다. lib를 변경할 때마다 다시 압축을 해야 합니다. 배치 파일을 사용하는 경우에도 마찬가지입니다.

  1. 컴퓨터의 로컬 git/svn 저장소에 업로드

이제 가까워지고 있지만 라이브러리를 변경하고 예제 구현을 테스트할 때마다 작성기 업데이트를 수행해야 합니다. 이것은 프로덕션을 모방하지만 번거롭습니다. 개인적으로 나는 이 솔루션을 추천합니다. 비록 두뇌가 없는 것은 아니지만.

  1. 라이브러리를 직접 자동 로드(sortof가 원하는 대로 수행)

이것은 해킹이지만 다음을 추가할 수 있습니다.

{    
  "require": {
  },
  "autoload": {
    "psr-4": { 
      "yourlibnamespace": "D:\\Code\\yourlib\\src\\" 
    }
  }

}

lib에서 샘플 구현으로 'require' 섹션을 복사하여 붙여넣어야 합니다. 'yourlibnamespace'를 라이브러리 네임스페이스로 변경하고 "D:\Code\yourlib\src\"를 라이브러리 소스에 대한 로컬 경로로 변경합니다.

이렇게 하면 모든 변경 사항이 즉시 반영됩니다. 그러나 라이브러리의 composer.json 파일을 전혀 사용하거나 테스트하지 않을 것입니다. 라이브러리 .json에서 요구 사항을 변경하면 전혀 흐르지 않습니다. 따라서 몇 가지 큰 단점이 있지만 가능한 한 최소한의 명령으로 라이브러리 구현을 즉시 테스트하는 원하는 작업을 수행합니다.

  1. 라이브러리 트리에 직접 예제 구현 추가 (권장)

일반적으로 src\ 및 tests\만 있지만 많은 경우 샘플 구현을 찾을 수 있는 examples\가 있습니다. 애플리케이션을 개발할 때 이러한 예제 구현에 기여할 수 있습니다. 로컬 git/svn repo에서 이 작업을 수행할 수 있으며 lib의 'require'와 네임스페이스를 자동으로 가져오는 이점이 있습니다. 그것은 모든 세계의 최고입니다. 이 방법을 추천합니다.


커스텀 리포지토리를 추가하면 도움이 될까요?

https://github.com/composer/composer/blob/master/doc/05-repositories.md

라이브러리와 함께 로컬 git 저장소를 매우 쉽게 설정할 수 있습니다.

물론 작곡가를 사용하여 종속성을 관리하는 경우 라이브러리를 다른 곳에서 빌드하고 공급업체에 다운로드해야 합니다.


이것이 로컬에서 새 Composer 패키지를 만들고 개발하는 내 흐름입니다.

  1. GitHub에서 패키지에 대한 새 리포지토리 생성(예시)
  2. Composer의 데이터베이스(packagist.org)에 추가합니다.
  3. composer require를 통해 메인 프로젝트에 추가하세요. 여기에서 핫픽스를 빠르게 적용할 수 있는 방법이 궁금해지기 시작합니다.
  4. 로컬 시스템 어딘가에 복제하십시오. 여기에서 개발하십시오.
  5. 이제 로컬 버전을 테스트하려면 해당 클래스 파일을 로드하는 php require() 문을 추가하십시오. 자동 로더는 작곡가를 통해 다운로드한 것이 아니라 로컬에서 다운로드한 것을 로드합니다.
  6. 핫픽스를 완료하면 require 문을 삭제/주석 처리하여 패키지의 작곡가 버전을 사용하도록 되돌립니다.
  7. 모든 변경 사항을 커밋하고 커밋에 태그를 지정하고 GitHub에 푸시합니다. 후크가 실행되어 Composer를 업데이트합니다. 기본 프로젝트에서 작곡가 업데이트를 실행하면 패키지가 로컬 버전으로 업데이트됩니다.

이것은 여전히 ​​이상적이지 않지만 중소 패키지에 대한 작업을 수행합니다.


개발을 보다 효율적으로 만들기 위해 개발 저장소를 이미 설치된 디렉토리에 심볼릭 링크하기만 하면 됩니다.

예를 들어 에 /Code/project-1있는 패키지가 필요한 경우 /Code/package-1I:

  1. package-1GitHub에 커밋 합니다(비공개일 수도 있음).
  2. 그런 다음 project-1사용자 지정 리포지토리를 사용하여 설치하도록 지시합니다(리포지토리 구성에 대한 링크에 대한 다른 답변 참조).
  3. 일단 설치되면 에 심볼릭 링크 /Code/project-1/vendor/developer/package-1합니다 /Code/package-1.

그렇게 하면 에서 변경 /Code/package-1하면 즉시 에 반영됩니다 /Code/project-1.


내 워크플로는 OP의 질문에 완전히 대답하지 않지만 다른 사람들에게 도움이 될 수 있습니다.

  1. 저는 실제 프로젝트에서 재사용 가능한 패키지/lib를 개발하는 것을 좋아하고 로컬에서 git/composer를 사용하고 싶지 않습니다.
  2. 또한 프로덕션과 비교하여 로컬에서 패키지를 다르게 로드하는 것도 좋아하지 않습니다(예: 로컬 require 문 또는 로컬 작성기 설정을 통해).

따라서 내가 하는 일은 간단합니다. 직접 또는 심볼릭 링크를 사용하여 공급업체 디렉토리 바로 아래에 패키지를 추가합니다.

단점

  1. 작곡가 업데이트/설치를 사용할 때 패키지를 덮어쓸 수 있습니다. (그래서 이 시간 동안 종속성을 하나씩 업데이트하거나 추가하는 경향이 있습니다).
  2. 주의하지 않으면 프로덕션 환경에 작곡가 설치가 다른 버전을 설치할 수 있습니다. 따라서 패키지 및 버전 태그를 계속 푸시하세요!!
  3. 패키지의 종속성을 변경하고 컴포저 업데이트를 통해 상위 프로젝트에서 로드하면 패키지의 폴더를 덮어씁니다.

ReferenceURL : https://stackoverflow.com/questions/14295558/how-to-develop-and-include-a-composer-package

반응형