이번 주 실습을 위해 이제 GENEREADME를 출시하게 되었습니다.

클레오벤트라 / 유전자 읽어보기

GENEREADME는 소스 코드 파일을 가져와서 LLM을 활용하여 파일의 코드를 설명하는 README.md 파일을 생성하는 명령줄 도구입니다.

기여

GENEREADME에 대한 기여를 환영합니다! 환경 설정, 도구 실행 및 테스트 방법, 변경 사항 제출에 대한 지침은 CONTRIBUTING.md를 확인하세요.

GENEREADME

GENEREADME는 파일을 가져와 처리하고 파일 내용에 대한 설명이나 문서가 포함된 README 파일을 생성하는 명령줄 도구입니다. 이 도구는 OpenAI 채팅 완성 기능을 활용하여 파일을 분석하고 콘텐츠를 생성합니다.

Releasing GENEREADME

사용방법

다음 명령을 실행하여 도구를

설치하세요.

npm i -g genereadme

로그인 후 복사

이 도구는 현재 기본적으로 Groq를 사용하는 Groq 및 OpenRouter를 지원합니다. 해당 공급자의 유효한 API 키를 제공해야 합니다.

다음 명령을 사용할 때 .env 파일을 생성하거나 -a 또는 --api-key 플래그를 통해 유효한 API 키를 제공하세요.

API_KEY=API_KEY

or

genereadme <files> -a API_KEY
genereadme <files> --api-key API_KEY

로그인 후 복사

기존 샘플 파일로 도구를 실행하거나 직접 사용하여 시작하세요.

…

GitHub에서 보기

프로세스

도구 게시 자체는 전혀 문제가 되지 않았지만 올바른 릴리스를 보장하기 위해 몇 가지 추가 단계를 수행해야 했습니다.

연구

릴리스 프로세스에 집중하기 전에 npm 레지스트리에 패키지를 게시하는 모범 사례와 단계를 조사하는 데 시간을 쏟았습니다. 제가 배운 내용은 다음과 같습니다.

1. npm에 패키지를 게시하는 방법
기본적인 프로세스를 이해하기 위해 공식 npm 문서를 참고했습니다. 이 가이드에서는 package.json 설정, npm 게시 실행, 버전 관리 등 필수 단계에 대한 개요를 제공했습니다.

2. 의미적 버전 관리 사용
버전 관리는 사용자에게 변경 사항을 알리는 데 중요한 역할을 합니다. 주요 변경 사항, 새로운 기능 및 버그 수정을 설명하기 위해 MAJOR.MINOR.PATCH 형식을 사용하는 Semantic Versioning의 원칙을 살펴보았습니다. 이를 통해 내 도구가 각 릴리스에 대해 의미 있는 버전 번호를 갖게 되었습니다.

3. .npmignore 관리
나는 npm 패키지에 최종 사용자에게 필요한 파일만 포함되도록 .npmignore 파일을 효과적으로 사용하는 방법을 조사했습니다. 이 파일을 신중하게 생성함으로써 게시된 패키지에 필요하지 않은 구성 파일, 테스트 및 문서와 같은 개발 관련 파일을 제외할 수 있었습니다. 이는 패키지의 크기를 줄일 뿐만 아니라 사용자가 도구를 실행하는 데 실제로 필요한 것에만 집중함으로써 패키지를 더욱 전문적으로 만들었습니다. .npmignore를 적절하게 관리하는 것은 세련된 릴리스를 준비하는 데 중요한 단계입니다.

풀어 주다

조사를 마친 후 요구 사항, 버그 가능성, 실패한 테스트를 다시 확인했습니다.
모든 것이 괜찮아 보이자 다음을 실행하여 패키지를 게시했습니다.

npm i -g genereadme

로그인 후 복사

참고: 이 명령을 실행하려면 사용자가 다음 명령을 실행하여 npm 계정에 로그인해야 합니다.

API_KEY=API_KEY

or

genereadme <files> -a API_KEY
genereadme <files> --api-key API_KEY

로그인 후 복사

테스트

이제 GENEREADME v1.0.0을 게시했으므로 일부 최종 사용자에게 패키지가 작동하는지 테스트하도록 요청할 차례입니다.
예상대로 몇 가지 버그가 발생했습니다. 도구의 성능에 영향을 주지 않는 것과 실제로는 도구를 손상시키는 것입니다.

조정

버전 명령 버그

발견된 간단한 버그는 genereadme -v 명령 사용에 관한 것입니다. 이 명령은 도구 이름과 현재 버전을 인쇄해야 합니다. 하지만 이 부분을 코딩한 방식은 현재 디렉터리의 package.json에서 프로젝트 이름과 버전을 검색하는 것입니다. 즉, 최종 사용자가 이 명령을 실행하면 내 대신 THEIR 프로젝트의 이름과 버전이 표시됩니다. 따라서 이는 항상 올바른 프로젝트에서 검색되도록 하는 간단한 수정이었습니다.

출력 디렉토리 버그

이것은 로컬 테스트에서 기술적으로 작동했던 도구를 손상시키는 버그인데 간단한 테스트 사례를 잊어버렸습니다.
프로젝트의 폴더 구조는 개발자와 기여자만 염두에 두고 있으므로 프로젝트에 출력 폴더가 있을 것으로 예상되며 출력의 샘플 결과가 포함된 기본 저장소에도 푸시했습니다.

이제 최종 사용자에 따라 조금씩 다를 것이라는 점을 명심해야 했습니다.
이전에는 출력/ 디렉토리의 존재 여부를 확인하지 않고 그냥 작성하고, 없으면 작성하도록 코드가 작성되었습니다. 이로 인해 최종 사용자에게 출력/ 디렉토리가 없기 때문에 게시된 패키지의 수동 테스트가 실패하게 되었으며, 존재하지 않는 경우 도구는 디렉토리를 만드는 대신 실패하게 됩니다.

이번 발견 이후에는 꽤 간단하게 생각했지요?
"좋아, 해결됐어!"라고 생각하면서 변경 사항을 적용해 보기 전까지는 말이죠. 그런데 놀랍게도 CI가 실패했습니다!

범인:

npm i -g genereadme

로그인 후 복사

이것이 내가 출력/디렉토리를 확인하고 생성하는 방법입니다. 그러나 엔드투엔드 테스트에서는 fs.existsSync()를 조롱하여 다음과 같은 이유로 false 값을 반환했습니다.

API_KEY=API_KEY

or

genereadme <files> -a API_KEY
genereadme <files> --api-key API_KEY

로그인 후 복사

이 함수는 fs.existsSync()를 사용하는 toml 구성 파일을 확인하며, 엔드투엔드 테스트에 toml 구성 파일을 사용하고 싶지 않았습니다. 이 메서드를 조롱하여 false를 반환했습니다. 제가 수행한 버그 수정과 충돌합니다.

저는 아직 모의 작업을 마스터하지 못했고 다양한 조건에 대해 동일한 방법에 대해 서로 다른 모의 값을 만드는 방법을 찾지 못했습니다. 그래서 해당 절차를 배울 때까지 모든 테스트 사례 전에 출력/디렉토리가 제거되도록 임시 수정 작업을 수행했습니다.

npm publish

로그인 후 복사

GENEREADME v1.0.4

이것으로 제가 만든 중요한 패치가 끝났습니다! 이제 GENEREADME를 사용할 수 있습니다!

위 내용은 GENEREADME 출시의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!