From b7f8eb9251ef6c65925f032c9c67b7b20032a168 Mon Sep 17 00:00:00 2001 From: sjungwon03 Date: Sun, 30 Aug 2026 15:22:20 +0900 Subject: [PATCH 1/5] docs: expand contribution note for #64466 --- contributions/64466.md | 31 +++++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-) diff --git a/contributions/64466.md b/contributions/64466.md index ce63405..567e455 100644 --- a/contributions/64466.md +++ b/contributions/64466.md @@ -2,9 +2,32 @@ pr-url: https://github.com/nodejs/node/pull/64466 --- +## 문제 내용 + +Node.js 문서를 읽는 과정에서 여러 오타와 잘못된 용어 표기를 발견했습니다. +API 문서, 기여 가이드, Crypto 서브시스템 안내 문서에 포함되어 있었으며, 일부는 ECMAScript 명세 링크의 참조 레이블에도 영향을 주고 있었습니다. + +주요 수정 대상은 다음과 같습니다. + +- `unresolveable` → `unresolvable` +- `descendent` → `descendant` +- `IsStrctEqual` → `IsStrictlyEqual` +- `writeable` → `writable` +- `mindfull` → `mindful` +- `triagging` → `triaging` +- `verions` → `versions` +- `forboding` → `foreboding` + ## 해결 과정과 검증 -- 발대식 이후 먼저 기여하신 분의 사례를 참고하여 기여를 진행하였습니다. [윤녹두님] -- 문서 수정 - - 문서에 있는 오타와 API 명세에 잘못 표기된 내용을 수정하였습니다. - - `fast-track` 라벨을 받아 하루 만에 머지되는 경험을 해보았습니다. +Node.js 저장소의 문서 파일을 검토해 오타를 수정했습니다. 특히 `writeable`은 Node.js API에서 사용하는 `Writable`, `WritableStream`, `napi_writable` 등의 용어와 일관되도록 `writable`로 변경했습니다. + +또한 N-API 문서의 ECMAScript Strict Equality 알고리즘 참조는 본문과 링크 레이블을 함께 수정하여, 문서 내 참조가 올바르게 연결되도록 했습니다. + +총 8개 문서 파일을 수정했으며, Pull Request의 CI에서 39개 검사가 모두 통과했습니다. 이후 리뷰어들의 승인과 fast-track 절차를 거쳐 `nodejs/node`의 `main` 브랜치에 병합되었습니다. + +## 배운 점 + +작은 문서 수정도 사용자 경험과 프로젝트의 신뢰성에 직접적인 영향을 준다는 점을 배웠습니다. 특히 기술 문서에서는 단순한 철자 교정뿐 아니라, 프로젝트의 기존 용어와 외부 명세의 공식 명칭을 함께 확인해야 합니다. + +또한 Node.js의 기여 과정에서 코드 변경이 아닌 문서 변경도 CI, 리뷰, 승인 절차를 동일하게 거친다는 점과, 유지보수자 및 리뷰어의 시간을 존중하는 기여 흐름을 경험했습니다. \ No newline at end of file From 1d67415e0b19d8c36a2670e691b478c45d39ddf5 Mon Sep 17 00:00:00 2001 From: sjungwon03 Date: Sun, 30 Aug 2026 15:22:20 +0900 Subject: [PATCH 2/5] docs: expand contribution note for #64486 --- contributions/64486.md | 26 +++++++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/contributions/64486.md b/contributions/64486.md index 400333f..2c5922f 100644 --- a/contributions/64486.md +++ b/contributions/64486.md @@ -2,8 +2,28 @@ pr-url: https://github.com/nodejs/node/pull/64486 --- +## 문제 내용 + +Node.js의 QUIC 내부 모듈을 확인하던 중, 테스트 커버리지 예외를 설명하는 TODO 주석에 `covrerage`라는 오타가 반복되어 있는 것을 발견했습니다. + +오타는 다음 5개 파일에 동일하게 포함되어 있었습니다. + +- `lib/internal/quic/diagnostics.js` +- `lib/internal/quic/quic.js` +- `lib/internal/quic/state.js` +- `lib/internal/quic/stats.js` +- `lib/internal/quic/symbols.js` + +기능 동작에는 영향을 주지 않지만, 유지보수자가 TODO의 의도를 빠르게 파악할 수 있도록 용어를 바로잡을 필요가 있었습니다. + ## 해결 과정과 검증 -- 오타 수정 - - 이전 기여 경험을 바탕으로 다시 한번 오타 수정으로 기여해보았습니다. - - 이전과 달리 `fast-track` 라벨을 받지 못해, 비교적 긴 시간이 지난 후 머지되는 과정도 경험해보았습니다. +각 파일의 TODO 주석에서 `covrerage`를 `coverage`로 수정했습니다. 변경 범위는 동일한 오타가 있는 QUIC 모듈 파일 5개로 한정했고, 동작 코드나 관련 없는 문서는 수정하지 않았습니다. + +Pull Request 생성 후 Node.js의 린트, QUIC 테스트, 운영체제별 테스트와 빌드 검사가 통과했습니다. 이후 여러 리뷰어의 승인을 받아 2026년 8월 1일 `main` 브랜치에 병합되었습니다. + +## 배운 점 + +작은 오타 수정이라도 변경 범위를 명확히 제한하는 것이 중요하다는 점을 배웠습니다. 특히 AI를 보조 도구로 사용할 때는 제안된 수정 내용을 그대로 넓게 적용하기보다, 실제 문제와 관련된 파일인지 직접 확인해야 합니다. + +이번 기여는 기능 개선보다는 코드 주석의 정확성과 유지보수성을 높인 작은 정비 작업이었습니다. \ No newline at end of file From 43a7eaac9f5b1832f3eb916259123c3eccbbcd97 Mon Sep 17 00:00:00 2001 From: sjungwon03 Date: Sun, 30 Aug 2026 15:22:20 +0900 Subject: [PATCH 3/5] docs: expand contribution note for #64754 --- contributions/64754.md | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/contributions/64754.md b/contributions/64754.md index 87bceb6..c2119ce 100644 --- a/contributions/64754.md +++ b/contributions/64754.md @@ -2,8 +2,20 @@ pr-url: https://github.com/nodejs/node/pull/64754 --- +## 문제 내용 + +스트림 반복자 소비자(`text()`, `textSync()`)는 `options.encoding` 값의 타입을 직접 검사하고 있었습니다. 이 방식은 Node.js 내부에서 공통으로 사용하는 인자 검증 방식과 중복되며, 잘못된 타입의 `encoding` 값에 대한 테스트도 충분하지 않았습니다. + ## 해결 과정과 검증 -- 코드 수정 - - 오프라인 모임에서 설명해주신 Node.js 코드 수정 방법을 활용하여 실제 코드를 수정하고 기여해보았습니다. - - 멘토님께서 가이드해주신 기여 포인트 중 하나인 validator 중복 코드를 수정하는 작업으로 기여하였습니다. +`lib/internal/streams/iter/consumers.js`의 수동 타입 검사를 공통 검증 함수인 `validateString()`으로 교체했습니다. 기존과 같은 오류 동작을 유지하면서, 검증 로직을 다른 내부 API와 일관된 방식으로 정리했습니다. + +또한 `test/parallel/test-stream-iter-consumers-text.js`에 문자열이 아닌 `encoding` 값을 전달하는 테스트를 추가했습니다. 비동기 `text()`와 동기 `textSync()` 모두에서 잘못된 입력이 적절히 거부되는지 확인했습니다. + +변경은 구현 파일 1개와 테스트 파일 1개로 제한했습니다. 린트, Linux·macOS·Windows 테스트, 커버리지 및 빌드 검사가 통과했으며, 리뷰 승인 후 2026년 8월 1일 `main` 브랜치에 병합되었습니다. + +## 배운 점 + +기존 코드를 공통 검증 유틸리티로 통일하면 오류 형식과 유지보수 방식을 일관되게 관리할 수 있습니다. 또한 리팩터링은 기존 동작을 보존하는 데서 끝나지 않고, 잘못된 입력값을 다루는 테스트를 함께 추가해야 안전하다는 점을 배웠습니다. + +이번 변경은 문서나 관련 없는 파일을 건드리지 않고, 스트림 소비자의 입력 검증과 회귀 테스트에만 집중했습니다. \ No newline at end of file From 93bdf55e0b661223cd108f654f9dced4dcaa1a5b Mon Sep 17 00:00:00 2001 From: sjungwon03 Date: Sun, 30 Aug 2026 15:22:20 +0900 Subject: [PATCH 4/5] docs: add contribution note for #65418 --- contributions/65418.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 contributions/65418.md diff --git a/contributions/65418.md b/contributions/65418.md new file mode 100644 index 0000000..4639f60 --- /dev/null +++ b/contributions/65418.md @@ -0,0 +1,21 @@ +--- +pr-url: https://github.com/nodejs/node/pull/65418 +--- + +## 문제 내용 + +`Module.builtinModules`에는 사용자 코드에서 접근할 수 있는 내장 모듈만 포함되어야 합니다. 하지만 기존 구현은 실험적 기능 플래그가 비활성화된 경우에도 `node:dtls`, `node:quic`, `node:ffi`, `node:vfs` 같은 scheme-only 내장 모듈을 후보 목록에 먼저 추가한 뒤, CommonJS 초기화 단계에서 다시 제거하고 있었습니다. + +이 과정은 실제 `require('node:...')` 접근 정책과 목록 생성 로직이 분리되어 있어, 두 로직의 조건이 달라질 가능성이 있는 구조였습니다. + +## 해결 과정과 검증 + +실험적 기능 플래그 처리 과정에서 이미 구성되는 “사용자에게 허용된 내장 모듈” 집합을 기준으로 `Module.builtinModules`의 scheme-only 항목을 생성하도록 변경했습니다. 이로써 중복된 플래그별 필터링 로직을 제거하고, `Module.builtinModules`와 `require('node:...')`의 접근 정책을 일관되게 유지하도록 했습니다. + +`node:test`, `node:sea`, `node:sqlite`처럼 기존에도 노출되던 scheme-only 모듈은 계속 목록에 포함되는지 확인했습니다. 또한 각 실험적 기능 플래그의 활성화·비활성화 상황에서 `Module.builtinModules`의 노출 여부와 `require('node:...')` 동작을 검증하는 테스트를 추가했습니다. + +## 기여 회고 + +같은 정보를 여러 단계에서 각각 필터링하면 시간이 지날수록 동작 불일치가 발생할 수 있다는 점을 배웠습니다. 이미 신뢰할 수 있는 사용자 접근 가능 모듈 집합이 있다면, 이를 단일 기준으로 삼아 파생 목록을 만드는 편이 더 안전하고 유지보수하기 쉽습니다. + +또한 실험적 기능은 플래그의 활성화 여부에 따라 공개 API가 달라지므로, 활성화된 경우뿐 아니라 비활성화된 경우까지 테스트하는 것이 중요하다는 점을 확인했습니다. \ No newline at end of file From 663bdb73d1e53729782bcf5774b53ab9bae528b0 Mon Sep 17 00:00:00 2001 From: sjungwon03 Date: Sun, 30 Aug 2026 15:22:20 +0900 Subject: [PATCH 5/5] docs: add contribution note for #65574 --- contributions/65574.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 contributions/65574.md diff --git a/contributions/65574.md b/contributions/65574.md new file mode 100644 index 0000000..975d47c --- /dev/null +++ b/contributions/65574.md @@ -0,0 +1,23 @@ +--- +pr-url: https://github.com/nodejs/node/pull/65574 +--- + +## 문제 내용 + +Node.js 내부 바인딩 중 `performance` 바인딩에는 TypeScript 선언 파일이 없어, 내부 바인딩을 사용하는 코드에서 제공하는 API와 타입 정보를 정적으로 확인하기 어려웠습니다. + +특히 히스토그램 핸들, Performance Observer 관련 훅, 상수, 타이밍 데이터의 형태가 타입 시스템에 표현되어 있지 않아 내부 API 변경 시 타입 검증의 도움을 받을 수 없었습니다. + +## 해결 과정과 검증 + +`typings/internalBinding/performance.d.ts`를 추가하고, `InternalBindingMap`에 `performance` 바인딩을 등록했습니다. 선언 파일에는 히스토그램 핸들, Performance Observer 훅, 상수, 타이밍 데이터 등 실제 바인딩이 제공하는 항목의 타입을 정의했습니다. + +구현은 기존 내부 바인딩의 형태와 다른 선언 파일의 작성 방식을 참고해 작성했으며, 변경 범위는 전역 타입 맵과 새 `performance` 바인딩 선언 파일로 제한했습니다. + +PR에서 Linux 및 ARM Linux 테스트, 문서 빌드, JavaScript·Markdown·YAML 린트 등 실행된 검사가 통과했습니다. + +## 기여 회고 + +내부 API의 타입 선언은 런타임 동작을 바꾸지 않지만, API 구조를 명확히 하고 이후 변경에서 타입 오류를 빠르게 발견할 수 있게 해준다는 점을 배웠습니다. + +AI를 보조 도구로 활용하더라도, 생성된 타입이 실제 바인딩의 속성·반환값·사용 방식과 일치하는지 기존 구현과 선언 패턴을 기준으로 직접 검토하는 과정이 중요하다고 느꼈습니다. \ No newline at end of file