GitHub Actions를 사용하여 gimme_readme를 npm에 다시 게시

이번 주 오픈 소스 수업에서 반 친구들과 저는 각자의 프로그램을 패키지 레지스트리에 게시하는 임무를 받았습니다.

누군가가 코드 레지스트리, 패키지 레지스트리 또는 레지스트리라는 말을 들을 때 저는 이러한 단어가 개발자와 회사가 다른 사람이 다운로드할 수 있도록 코드를 게시하는 장소를 나타내는 것으로 생각하고 싶습니다. 더 정확한 설명을 보려면 Mozilla의 다음 기사를 읽어보세요.

패키지 관리 기본 사항 - 웹 개발 알아보기 | MDN

이로써 패키지 관리자 둘러보기가 끝났습니다. 다음 단계는 샘플 툴체인을 구축하여 지금까지 배운 모든 내용을 실제로 적용하는 것입니다.

gimme_readme - npm

gimme_readme는 프로젝트에 대한 포괄적인 README.md 파일을 생성하는 AI 기반 명령줄 도구입니다. 여러 소스 코드 파일을 한 번에 분석하여 각 파일의 목적, 기능 및 주요 구성 요소에 대한 간결한 설명을 제공합니다. 최신 버전: 1.0.0, 마지막 게시: 16시간 전. `npm i gimme_readme`를 실행하여 프로젝트에서 gimme_readme 사용을 시작하세요. gimme_readme를 사용하는 npm 레지스트리에는 다른 프로젝트가 없습니다.

위에서 볼 수 있듯이 (개발자가 아닌) 사용자에게 불필요한 폴더와 파일이 많이 있습니다. 예를 들어, 내 사용자가 내 프로그램 코드를 테스트하기 위해 내 "tests" 폴더를 원한다고 생각하십니까? 아마 아닐 겁니다. 내 소스 코드의 형식을 지정하고 린트하는 데 필요한 구성 파일이 내 사용자에게 필요하다고 생각하시나요? 아마 아닐 겁니다. 내 사용자가 어떤 특별한 이유로 내 ".github" 폴더를 사용해야 한다고 생각하시나요? 아마 아닐 겁니다.

이를 위해 저는 사용자가 다운로드하는 것을 최소화하는 솔루션을 찾기 위해 노력해 왔습니다. 특히, 내 프로그램을 실행하는 데 필요한 소스 코드만 갖고 싶습니다.

.npmignore를 사용하거나 .npmignore를 사용하지 않으려면? 그것이 문제입니다.

코드를 다시 게시하려고 생각하면서 게시하고 싶지 않은 파일을 "무시"하기 위해 .npmignore 파일을 사용하는 아이디어에 대해 친구 Uday Rana와 이야기도 나누었습니다.

주제를 언급한 직후 Uday는 .npmignore를 검색하여 .npmignore 파일을 절대 사용해서는 안되는 이유에 대해 Jeff D가 작성한 기사를 찾았습니다. 분명히 말하면 저는 Jeff의 기사에 전적으로 동의합니다.

기본적으로 게시하려는 파일을 명시해야 하며, 게시하지 않는원하는 내용(허용 목록)을 명시

해야 한다는 것입니다. > 게시하고 싶습니다(블랙리스트에 등록).

npm을 사용하면 게시하려는 파일을 화이트리스트에 추가하는 것이 간단합니다. 우리가 해야 할 일은 프로그램에 게시하려는 파일을 나타내는 "files" 옵션을 추가하여 package.json 파일을 편집하는 것뿐입니다.

아래에서는 "이 프로그램을 게시할 때 src/ 디렉터리를 포함합니다"라고 명시되어 있는 package.json의 "files" 옵션에 대한 스크린샷을 찍었습니다. 이후 이러한 변경 사항을 커밋했으며 이러한 변경 사항은 내 코드의 v1.0.0 릴리스에서 사용할 수 있습니다.

참고: 기본적으로 특정 파일은 "파일" 옵션에 지정하거나 지정하지 않은 것과 관계없이 항상 npm에 게시됩니다. "files" 옵션 사용 방법에 대해 자세히 알아보려면 파일 옵션 사용 방법에 대한 npm 공식 문서를 확인하세요.

업데이트된 package.json을 사용하여 내 코드를 npm에 게시한 후 gimme_readme를 설치/재설치하는 사용자는 이제 컴퓨터에 부담을 덜 느끼게 됩니다! 아래의 차이점을 확인하세요.

새 릴리스를 추가할 때 내 코드를 npm에 게시하는 GitHub 작업 추가

사용자 경험을 향상시키는 것 외에도(npm을 통해 gimme_readme를 설치하는 데 따른 팽창을 줄임으로써), 새 프로젝트를 만들 때 게시 프로세스를 npm으로 자동화하는 지속적인 개발 파이프라인(간단히 CD 파이프라인)도 추가했습니다. GitHub에 출시하세요. 이를 수행하는 방법에 대한 정확한 세부사항은 GitHub의 Node.js 패키지 게시 가이드를 참조하세요. 지금은 기분이 좋습니다. 버튼 몇 번만 클릭하면 (내 CI 파이프라인에 따라) 안정적인 코드를 GitHub에서 게시할 수 있기 때문입니다.

내 CD 파이프라인의 코드는 여기에서 찾을 수 있습니다.

Uday로 테스트하기

앞서 말씀드린 것처럼 저는 친구인 Uday Rana와 함께 테스트 관련 작업을 하고 있었습니다. 글을 쓰는 시점에 그는 내 도구를 설치하고 다음과 같이 사용할 수 있었습니다.

제 생각에는 상황이 좋아 보이고 도구에 대해 제가 가진 옵션 중 대부분이 그가 기대하는 대로 작동합니다. 하지만 추가하고 싶은 최적화가 있기 때문에 이 과정을 다시 반복해야 합니다!

여행은 끝나지 않습니다... 하지만 그게 바로 재미를 주는 이유입니다!

최근에는 코드를 더욱 최적화할 수 있는 방법에 대해서도 들었습니다. 특히 복합 작업과 GitHub 작업과 관련된 재사용 가능한 워크플로를 학습하여 CI 및 CD 파이프라인을 개선하는 방법을 배우는 데 투자하고 있습니다. 나는 이러한 기술이 내가 작성하는 코드의 양을 줄이고 일종의 성능 향상을 제공하는 데 도움이 되기를 바랍니다. 아직 이 주제에 대해 잘 모르지만 조만간 블로그에 올리게 될 것 같습니다.

이것으로 제가 이 블로그에서 이야기하고 싶었던 내용이 끝났습니다.

다음에 또 만나요!

위 내용은 GitHub Actions를 사용하여 gimme_readme를 npm에 다시 게시의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!