컴포저(Composer) 공식 가이드 번역 - 2. 기본사용법

기본사용법

인트로

기본 사용법을 위해 로깅 라이브러리인  monolog/monolog, 를 설치할 것이다. 만일, 아직 컴포저를 설치하지 않았다면  Intro 를 참조하라.

주의: 단순함을 위해 이 글은 당신이 컴포저의 로컬 인스톨(a local install of Composer)을 수행한다고 가정한다.

composer.json: 프로젝트셋업

프로젝트에서 컴포저를 시작하려면 composer.json 파일이 필요하다. 이파일은 프로젝트의 의존성을 나타내고 다른 메타데이터도 포함할 수 있다.

require 키

 composer.json 에 처음으로 명시해야할 것은(종종 유일할 수도 있음) require 키 이다. 이는 컴포저에게 프로젝트가 어떤 패키지에 의존하고있는지를 말하는 것이다

{
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

보다시피, require 는  패키지네임(package names) (e.g. monolog/monolog) 을 버전제약(version constraints) (e.g. 1.0.*)로 맵핑하는 오브젝트(object)를 취한다.

패키지네임(Package Names)

패키지네임은 벤더네임(vendor name)과 프로젝트네임으로 구성된다. 종종 이둘은 동일하다-벤더네임은 단지  네이밍충돌(naming clashes)을 막으려고 존재한다. 이는 두사람이  json이라고 명명된 하나의 라이브러리를 만들수 있도록 하는데 이는 igorw/json 과seldaek/json으로 이름지어질 수도 있다. 

우리의 예에서는 monolog/monolog을 요구하는데 따라서 벤더네임이 프로젝트네임과 같다. 프로젝트를위해선 유니크(unique)한 네임이 추천된다. 이는 나중에 같은 네임스페이스아래서 더 많은 프로젝트를 추가할 수 있도록해준다. 만일 당신이 라이브러리를  관리하고있다면 더 작은 디커플된 파트(smaller decoupled parts)로 나누는 것을 쉽게해준다.

패키지버전(Package Versions)

이전예에서 우리는 Monolog의  1.0.* 버전을 요구하고 있었다. 이것은  1.0개발브랜치(development branch)의 모든 버전을 의미한다. 이는  >=1.0 <1.1와 매치하는 버전들을 말하는 것과 동일하다.

버전제약(Version constraints)은 여러방식으로 명시될 수 있다. 이 토픽에대한 더깊은 설명은  versions 을 참조하라.

안정성(Stability)

디폴트로 오직 안정화된 릴리즈(stable releases)만이 고려대상이 된다. 만일, RC, beta, alpha 혹은 dev 버전을 원한다면  stability flags. 을 사용하여 그렇게 할 수 있다. 의존성 하나 하나 당 하는 것 대신 모든 패키지를 일괄적으로 하고싶다면 minimum-stability 세팅을 사용할 수 있다(To change that for all packages instead of doing per dependency you can also use the minimum-stability )

의존성 설치(Installing Dependencies)

프로젝트를 위한 정의된 의존성을 설치하려면 install 커맨드를 실행한다.

php composer.phar install

이는 제공된 버전제한(version constraint)에서 monolog/monolog 의  최신버전을 찾아  vendor 디렉토리에 다운로드할 것이다.  vendor. 이라는 디렉토리에 써드파티(third party) 코드를 넣는 것이 컨벤션(convention)이다. Monolog 경우는vendor/monolog/monolog.에 넣을 것이다.

팁: 만일 프로젝트를위해 git를 사용한다면, .gitignore에vendor를 추기하기를  원할 수 도 있다.

 당신은 정말 모든 코드를 당신의 저장소(repository)에 넣기를 원치않을 것이다.

당신은 install 커맨드가  composer.lock 파일도 만든다는 것을 발견할 것이다..

composer.lock - The Lock File

의존성을 설치하고 난 다음 컴포저는  composer.lock 파일에 설치된 정확한 버전의 목록을 작성한다. 이것은 프로젝트를 이 특정한 버전들에 잠가버린다.

당신의 애플리케이션의 composer.lock (composer.json과함께 )을 버전콘트롤에 커밋(Commit).

이것은 중요한데 왜냐하면 install 커맨드가  lock 파일이 존재하는지 확인하고 존재한다면 명시된 버전을 다운로드하기때문이다(composer.json 가 어떤 이야기를 하던간에).

이것은 프로젝트를 셋업한 누구나 의존성의 정확한 버전을 다운로드할 것이라는 의미이다. 당신의  CI 서버, 프로덕션 머신(production machines), 팀내의 다른 개발자들, 모든 것 그리고 모든 사람들이 동일한 의존성을 사용한다는 의미인데 이는 버그의 가능성을 경감시켜서 드플로이먼트(deployments)의 제한된 부분에만 영향을 미치게한다. 심지어 당신이 혼자 개발을 한다해도 6개월 후에 프로젝트를 재설치할때 심지어 의존성 릴리즈가 그 후로 많은 새로운 버전이 있다해도 당신은 설치된 의존성이 여전히 제대로 작동할 것이라고 확신을 가질수 있다.

만일 composer.lock 파일이 없다면 컴포저는 composer.json에서 의존성과 버전을 읽고 update 혹은 install 커맨드를 실행 후 lock 파일을 생성할 것이다.

이말은 만일 의존성 중에 새로운 버전이 있다면 자동으로 업데이트되지 않는다는 뜻이다. 새로운 버전을 업데이트하려면 update 커맨드를 사용한다. 그러면 최신의 부합되는 버전을 가져오고(composer.json 파일에 근거해서) 또 새로운 버전에따라  lock 파일을 업데이트한다..

php composer.phar update

주의: 컴포저는 composer.lock과 composer.json 가 싱크(synchronized)하지 않다면 install 커맨드를 실행할때 경고싸인을 표시한다.

만일, 단지 하나의 의존성을 설치 혹은 업데이트하고자 한다면 당신은 이를 백서작성(whitelist) 할 수 있다:

php composer.phar update monolog/monolog [...]

주의: 라이브러리를 위해서는 파일을 커밋하는 것이 필요치 않다., see also: Libraries - Lock file를 참조하라

Packagist

Packagist 는 메인 컴포저 저장소(repository)이다. 컴포저 저장소는 기본적으로 패키지 소스(package source)이다(당신이 패키지를 얻을 수 있는 장소). Packagist 는 모든 사람들이 사용할 수있는 중앙저장소(central repository)를 목적으로한다. 이말은 이곳에서 이용가능한 모든 패키지를 자동으로  require 할 수 있다는 뜻이다.

 Packagist website (packagist.org)에 가면 패키지를 둘러보고나 검색할 수있다. 컴포저를 사용하는 모든 오프소스 프로젝트는  Packagist에 그들의 패키지를 퍼블리싱하기를 추천한다. 라이브러리는 컴포저로 사용되기위해 Packagist 에 꼭 있어야하는 것은 아니지만  Packagist 에 있으면 다른 개발자들이 이을 찾고 적용하는 것을 편리하게 해준다.

오토로딩(Autoloading)

오토로드(autoload) 정보를 명시한 라이브러리(libraries) 는  vendor/autoload.php 파일을 컴포저가 생성한다. 당신은 단지 이 파일을 포함하면 무료로 오토로딩을 얻게된다. 

require __DIR__ . '/vendor/autoload.php';

이는 써드파티 코드를 사용하기 쉽게한다. 예를들어, 당신의 프로젝트가 Monolog를 의존한다면, 당신의 그로부터 클래스들을 사용하기 시작할 수있다. 그리고 그들은 모두 오토로딩 될 것이다.

$log = new Monolog\Logger('name');
$log->pushHandler(new Monolog\Handler\StreamHandler('app.log', Monolog\Logger::WARNING));
$log->addWarning('Foo');

또, autoload 파일을  composer.json 에 추가함으로써 당신은 당신 자신의 코드를 오토로더에 추가할 수 있다.

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

컴포저는  Acme 네임스페이스를위한  PSR-4 오토로더를 등록할 것이다.

당신은 네임스페이스와 디렉토리(directories) 사이의 맵을 정의할 수 있다(You define a mapping from namespaces to directories.)  vendor 디렉토리가 동일한 레벨(level)에서 그렇듯이 src 디렉토리가 당신의 프로젝트 루트에 있을 것이다.  src/Foo.php  Acme\Foo 클래스를 갖고있는  src/Foo.php  를 예로들어보자.

autoload 파일을 추가한 후, vendor/autoload.php 파일을 재생성하기위해  dump-autoload 을 재실행해야한다

그 파일을 포함(Including) 하는 것은 오토로더 인스턴스(autoloader instance)를 리턴한다. 따라서 당신은 그 인클루드콜(include call)의 리턴값을 저장할 수  있고  더 많은 네임스페이스를 추가할 수 있다. 이는 태스트 슈트에서의 오토로딩클래스에 유용하다, 예를들면(This can be useful for autoloading classes in a test suite, for example.)

$loader = require __DIR__ . '/vendor/autoload.php';
$loader->add('Acme\\Test\\', __DIR__);

PSR-4 오토로딩 뿐만 아니라, 컴포저는 PSR-0, 클래스맵(classmap) 그리고 파일 오토로딩(files autoloading)도 지원한다. autoload 참조하라

주의:컴포저는 그 자체의 오토로더를 제공한다. 만일 이를 사용하기를 원하지 않는다면 당신은 단지 vendor/composer/autoload_*.php 파일을 인클루드할 수 있다. 이는 당신이 당신 자신의 오토로더를 설정할 수 있는 연관배열(associative arrays)을 리턴한다.

원문 : https://getcomposer.org/doc/01-basic-usage.md