기본 사용법

설치하기

아직 컴포저를 설치하지 않았다면, 소개 챕터를 참고하시기 바랍니다.

composer.json: 프로젝트 셋업

프로젝트에서 컴포저를 사용하기 위해서 필요한 것은 모두 composer.json파일에 있습니다. 이파일은 프로젝트의 의존성과 함께 많은 메타정보를 담고 있습니다.

JSON 포맷은 중첩된 구조를 정의하고 작성하는데 매우 쉬운 포맷입니다.

require key

composer.json에서 처음으로 살펴볼 것은 매번 확인하게 되는 require키입니다. 이 키는 컴포저에게 프로젝트가 어떤 패키지들을 필요로 하는지 알려줍니다.

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

보시는 바와 같이 require 는 패키지 이름 (e.g. monolog/monolog) 과 패키지 버전 (e.g. 1.0.*)의 맵핑 형태로 된 객체들로 표현됩니다.

패키지 이름

패키지 이름은 벤더의 이름과 프로젝트의 이름으로 구성되어져 있습니다. 벤더 이름은 동일한 패키지 이름을 충돌을 방지하기 위해서 존재합니다(종종 동일한 패키지가 존재할 수 있습니다). 만약 각각 다른 두명의 사람이 json이라는 라이브러리를 만들더라도, 둘다 igorw/json 그리고 seldaek/json와 같이 구분하여 사용할 수 있게 해줍니다.

위에서 예시로든 monolog/monolog의 경우에는 벤더의 이름과 패키지 이름이 동일한 경우 입니다. 프로젝트가 하나만 존재하는 경우에는 이렇게 구성하는것이 권장됩니다. 또한 나중에 관련된 프로젝트를 동일한 이름에 더 추가할 수도 있습니다. 만약 라이브러리를 유지 보수한다면, 더 작은 부분들로 이루어 질 수 있도록 손쉽게 분리 할 수 있습니다.

패키지 버전

이전 예제에서 monolog 의 1.0.* 버전을 필요로 하다고 설정했습니다. 이 의미는 어떠한 1.0 브랜치도 가능하다는 뜻입니다. 따라서 버전이 1.0.0이 될수도 1.0.2 또는 1.0.20이 될수도 있습니다.

버전의 표시는 몇가지 다른 방법으로 지정할 수 있습니다.

다음 주요 릴리즈 (물결표 와 삽입기호(^)표현)

~ 물결표 표현은 예를 들어서 보는것이 제일 좋습니다. ~1.2은 >=1.2 <2.0.0와 동일하고, ~1.2.3은 >=1.2.3 <1.3.0와 의미가 같습니다. 이러한 표현은 시멘틱 버저닝을 따르는 프로젝트에 있어서 매우 유용합니다. 일반적으로 ~1.2와 같이 최소버전을 표시하는 형식으로 사용되어집니다. (이상의 버전을 의미하지만 2.0 버전을 포함하지는 않음). 이러한 버저닝이 유지되려면 2.0 버전 이전까지는 호환성에 아무런 문제가 없어야 합니다. 위에서 보다시피 ~ 을 사용해서 최소버전을 지정하면, 지정된 마지막 자리까지만 허용하게 됩니다.

^ 삽입기호 표현은 시멘틱 버저닝의 표현과 비슷하게 동작하지만 다른 형태의 업데이트까지 허용합니다. 예를 들면 ^1.2.3은 2.0 버전 미만의 호환성을 유지하는 >=1.2.3 <2.0.0 까지를 의미합니다. 또한 ^0.3은 >=0.3.0 <0.4.0과 동일한 의미를 지닙니다.

주의: 비록 2.0-beta.1은 엄밀히 말해서 2.0 이전 버전이라고 할 수 있지만 ~1.2으로 표시되었을 때 이버전을 설치하지는 않습니다. 다시말해서 ~1.2 는 .2 버전만을 의미합니다. 뒤의 버전은 변경될 수 있지만 1. 부분은 고정된 형식입니다.

주의: ~ 물결표 표현은 메이저 릴리즈 버전을 표시할 때 예외적으로 동작합니다. 이 말은 ~1 으로 표현한 버전은 ~1.0과 동일한 의미를 가지며 메이저 릴리즈가 업데이트 되기 전까지의 버전을 지칭한다고 할 수 있습니다.

Stability 버전 안정성

기본적으로 버전 표시의 고려대상으로은 안정화 버전(stable)만을 의미합니다. 만약 RC, 베타, 알파 또는 개발 버전과 같은 표현이 필요하다면 안정성 표시기호를 참고하십시오. 패키지의 의존성을 표시하는데 이러한 안정성 표현이 필요하다면 최소 안정성 셋팅을 참고하십시오.

의존 패키지 설치하기

의존관계가 선언된 패키지들을 로컬 프로젝트로 다운받기 위해서는 다음과 같이 composer.phar의 install 명령어를 입력하면 됩니다.

php composer.phar install

이 명령어를 입력하면 monolog/monolog 패키지의 매칭 되는 가장 최신버전을 vendor디렉토리에 다운로드 받습니다. vendor 디렉토리는 서드파티의 패키지들이 다운로드 되는 폴더를 의미합니다. 위에서 살펴본 monolog 경우에는 vendor/monolog/monolog에 다운로드 됩니다.

참고: 프로젝트를 git으로 관리하고 있는 경우에 모든 서드파티의 코드가 추가되길 원하지 않는다면 vendor 디렉토리를 .gitignore에 추가하여 관리하면 됩니다.

install 명령어를 통해서 의존관계가 설정된 패키지들 설치한 후에는 composer.lock파일이 프로젝트 루트 디렉토리에 생성됩니다.

composer.lock - 잠금 설정 파일

의존성 패키지들을 설치한 뒤에 컴포저는 composer.lock파일에 설치한 패키지들의 정확한 버전 목록을 저장합니다. 이 잠금설정들이 프로젝트가 필요로 하는 특정 버전들을 의미합니다.

**어플리케이션의 composer.lock파일을 (composer.json파일과 함께) VCS 플 통해서 커밋하십시오. **

install명령어는 이 잠금파일이 디렉토리에 존재하는지 확인하고 만약 그렇다면 (composer.json에 관계없이) 잠금설정된 버전의 패키지들을 다운받습니다.

이것이 의미하는 것은 프로젝트를 셋업하고 의존성 패키지들을 다운로드 하려고 하는 그 어떤 누구라도 동일한 버전의 의존 패키지들을 다운로드 한다는 것을 의미합니다. CI서버, 실제의 제품 서버, 같은 팀내의 다른 개발자 모두가 동일한 의존성기반하에 프로젝트를 구동한 다는 것은 배포를 비롯한 일부 패키지들에 영향을 미치는 버그에 대한 가능성을 완화시켜 준다는 것을 의미합니다. 혹시나 혼자서 개발할지라도 6개월만에 다시 인스톨해야하는 프로젝트의 경우 그동안 의존성 패키지들의 새로운 버전이 나왔더라도 동일하게 작동하는 의존 패키지들을 다운로드 받을 수 있다는 것을 말합니다.

만약 composer.lock 파일이 존재하지 않는다면 컴포저는 composer.json의로 부터 의존성과 버전 정보를 읽어 들여 update 명령어나 install명령이 실행된 이후에 lock 파일을 생성합니다.

이 말은 어떤 새로운 의존성 패키지가 새롭게 업데이트 되더라도 자동으로 업데이트 할 수 없다는 것을 의미합니다. 새로운 버전으로 업데이트 받기 위해서는 update 명령어를 사용합니다. 그렇게 하면 버전에 알맞는(composer.json 파일에 맞는) 최신의 패키지를 업데이트 하고 lock 파일을 새롭게 생성하게 됩니다.

php composer.phar update

주의: 컴포저는 composer.lock 파일과 composer.json 파일의 정보가 동기화 되어 있지 않다면 install명령어 수행시 경고를 표시합니다.

만약 하나의 의존 패키지들을 설치하거나 업데이트 하고자 한다면 다음처럼 각각의 패키지들을 나열하여 실행할 수 있습니다.

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

주의: 라이브러리에는 lock 파일을 커밋하는 것이 불필요 합니다 . 보다 자세한 사항은: Libraries - Lock file을 참고하십시오.

Packagist - 패키지스트

Packagist는 주요한 컴포저 저장소입니다. 컴포저 저장소란 기본적으로 패키지를 얻을 수 있는 곳을 의미합니다. 패키지스트는 모두가 사용할 수 있는 중앙저장소가 되는 것을 목표로 하고 있는데, 이 말은 즉 패키지스트에 올라와 있는 모든 패키지들은 require 할 수 있다는 것을 의미합니다.

패키지스트 웹사이트 (packagist.org)에 접속하면, 패키지들에 대해서 검색하고 상세한 정보를 확인할 수 있습니다.

컴포저를 사용하는 오픈소스 프로젝트라면 컴포저를 통해서 프로젝트를 패키지스트에 게시하는 것이 좋습니다. 라이브러리 타입의 경우에는 꼭 패키지스트에 있을 필요는 없지만 그렇게 하는 것이 좀 더 사용을 쉽게 할 수 있습니다.

Autoloading - 오토로딩

컴포저는 라이브러리들에 대한 오토로딩 정보를 vendor/autoload.php 파일에 저장합니다. 이 파일을 include 함으로써 오도로딩을 손쉽게 적용할 수 있습니다.

require 'vendor/autoload.php';

이렇게 함으로써 서드파티의 코드를를 사용하는 것을 아주 쉽게 만들어 줍니다. 예를 들어 : 작성하고 있는 프로젝트가 monolog 에 의존성을 가지고 있을 때 오토로딩을 사용하면 바로 해당 클래스를 사용할 수 있다는 것을 의미합니다.

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

오토로딩의 설정은 composer.json 의 autoload 설정을 통해서도 할 수 있습니다.

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

위의 경우 컴포저는 Acme 네임스페이스를 PSR-4에 따라서 오토로딩을 설정합니다. 오토로딩은 네임스페이스에 대한 디렉토리 매핑을 정의합니다. src 디렉토리는 vendor 디렉토리와 마찬가지로 프로젝트 루트 디렉토리에 존재합니다. 예를 들어 src/Foo.php 파일은 Acme\Foo 클래스를 의미합니다.

autoload 항목을 추가한 뒤에는 dump-autoload 명령어를 실행하여 vendor/autoload.php 파일을 재생성 해주어야 합니다.

autoload.php 파일을 include 하게 되면 오토로더 인스턴스를 리턴 받을 수 있습니다. 이 리턴받은 인스턴스를 통해서 추가적인 네임스페이스를 지정할 수도 있습니다. 테스트가 필요한 경우 다음 예제처럼 유용하게 사용할 수 있습니다.

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

PSR-4 오토로딩 이외에도 classmap 형태의 오토로딩도 지원합니다. 이 경우 PSR-4 형식에 맞지 않더라도 클래스를 오토로딩할 수 있습니다. 보다 자세한 정보는 autoload reference을 참고하십시오.

주의: 컴포저는 자체적인 오토로더를 제공합니다. 컴포저의 자체적인 오토로더를 사용하지 않는 경우 연관된 배열을 리턴하게끔 구성된 vendor/composer/autoload_*.php 파일들을 include 하여 고유한 오토로더를 구성할 수 도 있습니다.