Auto: 플러그인: 시맨틱 릴리스 스타일 커밋 메시지를 기반으로 PR 레이블 적용

ESM에 의존하는 방식이 상당히 이상합니다.

프로덕션이 아닌 빌드에 esm을 사용해야 합니다.

빌드하고 dist 폴더를 게시하는 대신 babel-register를 사용하는 것과 같습니다.

저도 처음에는 같은 생각을 했지만 소스 코드를 보면 다르게 나와 있습니다.

편집: 오 nvm, 게시하기 전에 esm 를 사용하여 컴파일할 수 있다고 말씀하셨습니다. PR을 보내야 합니다.

그렇지 않으면 좋은 모듈처럼 보입니다. 착하고 마른

esm 가 컴파일용으로 만들어지지 않은 것 같습니다: https://github.com/standard-things/esm/issues/13#issuecomment -321710199

지금은 분기하고 import 및 export 구문을 CommonJS로 변환합니다.

흠 예, 방금 readme를 읽고 있었습니다. 제가 잘못 이해한듯

esm은 65kb를 추가하는 것 같습니다 😮

https://packagephobia.now.sh/result?p=parse-commit-message
https://bundlephobia.com/[email protected]

https://github.com/developit/microbundle 로 전환하는 홍보를 만들고 아마도 추가할 것입니다.

대신 https://github.com/egoist/bili 를 사용하는 것을 고려해야 합니다. 설치 크기는 절반이지만 다른 절충 사항이 있을 수 있습니다. 확실하지 않다.

https://github.com/tunnckoCoreLabs/parse-commit-message/pull/55

Btw, 파티에 참여합니다. git-commits-since 및 detect-next-version 가 여기에 더 도움이 될까요?

보장과 노드의 esm 기능 플래그 뒤에 있기 때문에 esm 를 사용하고 있습니다. ascjs 나 rewrite-imports 와 같은 유사한 것을 쉽게 사용할 수 있지만 esm 는 가져오기/내보내기보다 훨씬 더 많은 것을 지원합니다. 그리고 저는 빌드 단계나 다른 것을 _아무__ 하지 않았기 때문에 테스트를 위해 러너에 대한 후크로만 사용합니다.

이를 통해 ascjs 또는 asbundle 로 전환할 수 있습니다.

@aleclarson 크기가 왜 그렇게 큰 문제입니까? 노드 랜드에서도 패키지 관리자는 이미 중복을 제거할 만큼 똑똑합니다.

@aleclarson 크기가 왜 그렇게 큰 문제입니까? 노드 랜드에서도 패키지 관리자는 이미 중복을 제거할 만큼 똑똑합니다.

중복 의존성을 우려한 적이 없습니다. 나는 일반적으로 부풀려진 도구를 조심할 뿐입니다. "가벼울수록 좋다"는 나의 경험 법칙이지만, 각자의 기준입니다. 나는 이것에 대해 토론하는 데 별로 관심이 없습니다. :)

Btw, 파티에 참여합니다. git-commits-since 및 detect-next-version 가 여기에 더 도움이 될까요?

나는 parse-commit-message 패키지가 이미 auto-release 에 존재하는 로직을 복제하는 것처럼 보이기 때문에 parse-commit-message 를 사용하는 것을 선호하지만 @hipstersmoothie 는 유지 관리 부담을 줄이기 위해 기존 로직을 해당 패키지로 교체할 것입니다.

:rocket: 문제가 10.0.0에서 릴리스되었습니다.