Rector 단독 규칙 패키지 운반
어느 것이 옳은 것이 아니라 마지막까지 읽어 주십시오.이번에 렉터의 경우 PHPStan도 같은 구성을 적용했다.
패키지 구조
오리 선생 글의 구성은 응용 프로그램과 같은 창고
rector/{src,tests}
에 디렉터리를 준비하고 있지만 저는 응용 프로그램 주체와 달리 Rector 전용 창고로 독자적인 Rector 규칙을 개발하고 있습니다.Rector뿐만 아니라 프로젝트 운영 시간과 관계없이 개발할 때 필요한 도구는 어디에 두고, 의존관계는 어디에 두느냐가 고민거리다.
기본적으로 독립된 것은 포장을 분리하는 것이 좋다고 생각하지만 Rector의 상황은 기록 대상이 프로젝트 주체에 정의된) 인터페이스와 추상류에 의존하기 때문에 공유하기 어려운 경우도 있다.Rector는 PHPStan을 기반으로 하여 변경 객체의 클래스를 잘못 정의하지 않아야 합니다.시험 성적이라도 마찬가지다.
단, 이 경우 독립된 프로젝트에 의존하는 클래스나 인터페이스를 복제하여 일부 제한을 의도적으로 삭제하여 규격변경을 준비할 수도 있다.
회사Satis에 사내 현지 포장을 보관하고 있기 때문에
pixiv/rector-pixiv
포장으로 등록되어 있습니다.버전은 날짜를 기초로 한다2020.11.2.0
.(Composier에서 날짜 버전을 사용할 때 2020.11.02
처럼 0
채우지 않도록 주의하세요)앞에서 말한 바와 같이 프로젝트 주체가 정의한 추상적인 클래스나 인터페이스는 복제하고 부분적으로 수정한 다음에
composer.json
의"autoload-dev"
에 자동으로 불러올 수 있다.설치하다.
회사의 제품은 프로젝트 자체가 아니며, Rector와 PHPStan은 하위 디렉터리에 설치되어 있습니다.
프로젝트 디렉터리 설정에서 개발용 도구와 스크립트 그룹은
dev-script
라는 디렉터리에 배치됩니다.dev-script/rector
는 자물쇠를 당기는 조개 각본으로 다음과 같다.#!/bin/bash
# rector 実行時に php-timecop が読み込まれないようにする
php --ini | grep -Eo '/.+\.ini' | xargs cat | grep -v timecop > "$(dirname "$0")/exclude-timecop.ini"
php -nc "$(dirname "$0")"/exclude-timecop.ini -dmemory_limit=${PHP_MEMORY_LIMIT:-128M} "$(dirname "$0")"/_rector/vendor/bin/rector "$@"
이것hnw/php-timecopPHPStan과 어울리지 않는 조치이다.현재 PHPStan은 영향을 받지 않지만 타임캡은 해석할 때 필요하지 않기 때문에 지금도 떼어냅니다.먼저 조개 스크립트
"$@"
는 각 파라미터를 모두 과장하여 교부하는 뜻으로 Rector가 받아들인 파라미터는 모두 직접 교부할 수 있다.dev-script/_phpstan/composer.json
는 다음과 같다.{
"name": "pixiv/rector",
"license": "proprietary",
"description": "rector",
"repositories": [
{
"packagist": false
},
{
"type": "composer",
"url": "http://satis.example.private/"
}
],
"require": {
"pixiv/rector-pixiv": "^2020.10",
"rector/rector-prefixed": "^0.8.45"
},
"config": {
"optimize-autoloader": true,
"classmap-authoritative": true,
"discard-changes": true,
"secure-http": false,
"preferred-install": "dist"
}
}
rector/rector-prefixed는 리코더를 Phar 압축 파일로 컴파일한 소프트웨어 패키지입니다.composer require pixiv/rector-pixiv rector/rector-prefixed
와 같이 포장을 지정하여 가져오는 것rector/rector
은 rector/rector-prefixed
의 대체품으로 복잡한 의존 관계의 해결을 피할 수 있다.이렇게 하면 독립된 규칙의 포장에 의존
rector/rector
하고 프로젝트 주체로 가져올 때rector/rector-prefixed
로 의존을 대체하며 개발할 때 필요하다면 Rector의 설치를 읽으면서 작업을 할 수 있다.휴식의 정도일 뿐 최적화
optimize-autoloader
와classmap-authoritative
를 위해 유효화하고 있다.secure-http
회사 내부의 Satis는 HTTP이기 때문에 설정했습니다(물론 이런 상황에서 설정하지 마십시오).이 PHP는 템플릿 엔진이야 너무 신중해 (전편) - Qita에서 설명한 바와 같이 Composer bin plugin도 같은 상황을 실현할 수 있다.
최근 제작된Bag2\Doppel에는 렉터를 사용하지 않았지만 PHPStan을 위시한QA 도구군은 tools 디렉토리 이하
make
에서만 가져올 수 있다.총결산
단순한 내용이라 총결산도 다 있는 건 아니지만, 렉터는 정확도 높은 유형의 정보를 얻으면서 문법 트리를 간단하게 가지고 놀아 즐거워했다.
공통 규칙은 쉽게 Rector 호스트로 전송됩니다.
Reference
이 문제에 관하여(Rector 단독 규칙 패키지 운반), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://zenn.dev/tadsan/articles/c051351286318896b199텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)