slugify: URL에 ‘!’가 왜 남아 있을까요?

slugify("Déjà Vu!", { lower: true, strict: true })
// → "deja-vu"

01. 원했던 URL

슬러그 표기는 사람이 읽을 수 있는 URL의 마지막 부분을 뜻합니다. 예를 들어 deja-vu 부분은 다음 URL의 슬러그입니다: example.com/posts/deja-vu. 이 예제는 실제 slugify 1.6.6 npm 릴리스를 사용합니다. 아래 결과는 해당 릴리스를 로컬에서 실행한 결과입니다.

아래 제목을 입력한 다음 구두점 제거 옵션을 켜고 차이를 확인하세요.

같은 비교를 JavaScript로 나타내면 다음과 같습니다:

slugify("Déjà Vu!")
// → "Deja-Vu!"

slugify("Déjà Vu!", { lower: true })
// → "deja-vu!"

악센트는 사라졌지만 느낌표는 남았습니다. REA로 패키지의 진입 파일을 찾고 필터링 코드를 읽어 어떤 옵션이 느낌표를 제거하는지 확인했습니다. 아래에서 같은 과정을 따라 할 수 있습니다.

02. 패키지를 다운로드하고 REA로 분석하기

버전이 고정된 npm tarball을 다운로드한 뒤 패키지를 설치하거나 실행하지 않고 압축을 풀었습니다. 다음 준비 명령에 필요한 셸 도구: tar:

mkdir rea-slugify-case
cd rea-slugify-case
npm pack slugify@1.6.6
tar -xzf slugify-1.6.6.tgz

그다음 압축을 푼 package 디렉터리에 REA의 JavaScript 애플리케이션 분석기를 실행했습니다:

코딩 에이전트를 사용하려면 경로를 바꾸고 다음 프롬프트를 붙여 넣으세요:

REA로 /absolute/path/to/rea-slugify-case/package를 분석하세요. 글 URL을 만들 때 slugify를 사용합니다. slugify('Déjà Vu!', { lower: true })에서 느낌표가 남는 이유는 무엇인가요? 진입 파일을 찾고 느낌표를 허용하는 코드를 보여 주며 이를 제거하는 옵션을 식별하세요. 패키지는 변경하지 마세요.

또는 터미널에서 직접 분석 결과를 수집하세요:

npx -y rea-agents@6.4.0 analyze-javascript-application ./package --json > analysis.json

REA가 식별한 패키지 이름은 slugify, 버전은 1.6.6, 진입점은 ./slugify.js입니다. 보고서는 관련 파일 3개와 파싱 실패 0건을 기록했습니다. 전체 그래프 분석 범위는 다음으로 표시되었습니다: 부분적. 공개 요약에서도 이 상태를 그대로 명시했습니다.

읽을 수 있는 JavaScript 배포본입니다. REA는 아티팩트 목록과 분석 맥락을 제공했고, 이후의 소스 확인과 직접 검증으로 동작을 확인했습니다. 네이티브 디컴파일은 사용하지 않았습니다.

03. 구두점을 제거하는 옵션 찾기

배포본에 포함된 slugify.js의 33–42행은 문자열 정규화, 로케일 또는 문자 맵 치환, 문자 필터링을 수행합니다. 기본 필터는 느낌표를 명시적으로 허용합니다.

// remove not allowed characters
.replace(options.remove || /[^\w\s$*_+~.()'"!\-:@]+/g, '')
}, '');

if (options.strict) {
  slug = slug.replace(/[^A-Za-z0-9\s]/g, '');
}

strict 분기는 이후에 실행되며 문자, 숫자, 공백 이외의 문자를 제거합니다. 소문자 변환은 57–58행에서 별도로 수행합니다. 이를 바탕으로 검증 가능한 예측을 세울 수 있습니다:

slugify("Déjà Vu!", { lower: true, strict: true })
// should return "deja-vu"

같은 파일은 여러 공백을 하나의 구분자로 합치는 이유도 설명합니다. 문자 치환은 & → and이며, 독일어 로케일에서는 Ä → AE.

04. 실제 패키지에서 검증 실행하기

수정하지 않은 1.6.6 릴리스에 원래 질문과 관련 동작 몇 가지를 포함해 단언문 8개를 실행했습니다.

기록된 검증 결과 읽기. 또는 위의 체험형 패키지 데모를 사용하세요. 데모는 같은 고정 버전 패키지를 브라우저에서 실행합니다.

05. 테스트한 범위

이 릴리스와 입력에서는 소스와 관찰된 출력이 일치합니다. 원하는 결과가 deja-vu라면 다음 두 옵션을 사용하세요: lower: true 및 strict: true.

배포된 소스를 읽을 수 있으므로 일반적인 소스 확인도 유효한 방법입니다. 이 사례는 아티팩트를 식별하고 규칙 하나를 분석한 다음 원본 구현으로 주장을 검증하는 전체 과정을 보여 줍니다.

06. 예제 다운로드 및 실행

작은 재현 키트를 다운로드하세요. 고정 버전 의존성, 단언문 8개, 직접 REA 검증 자료를 수집하는 절차가 포함되어 있습니다.

재현 키트 다운로드 ↓

npm install --ignore-scripts
node verify.mjs

검증 실행기는 각 결과를 출력하며 검증에 실패하면 오류 상태로 종료합니다. Node.js는 이 검증 단계에서만 npm 패키지를 실행합니다. 앞서 수행한 REA의 정적 분석은 패키지를 실행하지 않습니다.

REA가 처음인가요? REA란? · 가이드 검증 방법