검사 html 링크 도입 - 더 이상 나쁜 링크 없음

TL;DR: 웹 사이트/문서에서 끊어진 모든 링크를 복구하는 데 도움을 줄 수 있는 독립된 도구를 만들었습니다.너는 on npm as check-html-links을 볼 수 있다
제 개발자 생활에서 저는 이미 여러 사이트를 접속했습니다. 솔직히 말하면 보통 며칠 안에 이런 문제가 발생할 수 있습니다."xxx의 링크가 끊겼습니다."🤦‍♂️
이 일들은 위치마다 업데이트되는 것이 아니라 페이지가 이동하거나 이름이 바뀌는 곳에서 자주 발생한다.
특히 Word Press나 스파 같은 동적 페이지가 있다면 정말 포착하기 어렵다.사용자에게 있어서 404가 그들을 쳐다보고 있는 것보다 더 나쁜 것은 없다.
다행히도 SSG(정적 사이트 생성기)가 유행하면서 이 문제는 더욱 쉽게 해결되고 어느 정도 해결될 수 있게 되었다.그 이유는 모든 HTML이 정적 파일로 미리 보여지기 때문에 우리는 모든 HTML을 읽고 모든 링크를 검사할 수 있기 때문이다.

새로운 도구에 대한 평가 및 결정
물론, 나는 처음으로 이 생각을 제기한 사람이 아니다. 시장에는 이미 여러 가지 도구를 사용할 수 있다.
그러나 기존의 해결 방안을 검사할 때, 나는 그것들 중 대다수가 나를 만족시키지 못한다는 것을 발견했다. 적어도 길에서 이렇게😅. 내가 주의한 것은 실행 속도가 느리고 추천하지 않으며 의존 관계 트리가 크고 사용자 출력이 혼란스럽다는 것이다.
이러한 도구를 살펴보고 나는 자신의 도구를 만들고 다음과 같은 요구를 충족시키기로 결정했다.

급속 연소

사용자 중심 출력

소량의 종속성 -

감소

은 NodeJS 생태계에서

이 가장 좋습니다.

유용한 출력에 주목
대부분의 평가된 도구는 단독으로 파일을 검사하고 각자의 발견을 보고한다.이것은 만약 당신의 눈썹이나 꼬리에 끊어진 링크가 있다면, 매 페이지마다 한 줄 (심지어 여러 줄) 의 오류 메시지를 받을 수 있다는 것을 의미한다.
나는 11ty-website에서 테스트를 진행했는데 현재 501개의 파일 중 516개의 끊어진 링크가 있다.그러나 516개의 링크 끊기 원본은 13개의 부족한 페이지/자원에 불과하다.
내 실행 중, 나는 '파일 중심 오류' 방법에서 '파일 중심 오류' 방법으로 전환하기로 결정했다.예를 들어서 이걸 한번 보도록 하겠습니다.

파일 세트 오류
이것은 많은 기존 해결 방안이 실현한 것이다.다음은 결과 출력의 일부입니다.

[...]
authors/ryzokuken/index.html
  target does not exist --- authors/ryzokuken/index.html --> /speedlify/
authors/alex_kaul/index.html
  target does not exist --- authors/alex_kaul/index.html --> /speedlify/
docs/config/index.html
  target does not exist --- docs/config/index.html --> /speedlify/
  hash does not exist --- docs/config/index.html --> /docs/copy/#disabling-passthrough-file-copy
authors/cramforce/index.html
  target does not exist --- authors/cramforce/index.html --> /speedlify/
authors/accudio/index.html
  target does not exist --- authors/accudio/index.html --> /speedlify/
[...]

우리는 /speedlify/에서 약 2000줄의 오류를 얻었다. 왜냐하면 그것은 약 500번 발견되지 않았기 때문이다.이 오류들 중에서, 우리는 또 다른 끊어진 링크를 보았다.
보고서는 먼저 문서에 주목한 다음에 실제 오류에 주목하기 때문에 대부분의 오류의 출처를 알기 어렵다.

파일 분실
이 국면을 전환시켜 부족한 참고 문헌에 관심을 갖자.다음은 동일한 입력 웹 사이트의 출력입니다.

[...]
  1. missing reference target _site/speedlify/index.html
    from _site/404.html:1942:13 via href="/speedlify/"
    from _site/authors/_amorgunov/index.html:2031:13 via href="/speedlify/"
    from _site/authors/_coolcut/index.html:2031:13 via href="/speedlify/"
    ... 495 more references to this target

  2. missing id="disabling-passthrough-file-copy" in _site/docs/copy/index.html
    from _site/docs/config/index.html:2527:267 via href="/docs/copy/#disabling-passthrough-file-copy"

  3. missing reference target _site/authors/dkruythoff/github.com/dkruythoff/darius-codes
    from _site/authors/dkruythoff/index.html:2102:234 via href="github.com/dkruythoff/darius-codes"
[...]

/speedlify/에서 5줄 오류가 발생했습니다. 495회 + 3개의 예시적인 사용법이 부족하다는 것을 알려 줍니다.
이후에 우리는 더 많은 부족한 참고 문헌과 그것들이 발생한 곳을 분명히 발견했다.

명백한 승자
이 두 출력 결과를 비교해 보면 일부 링크가 곳곳에서 파괴될 수 있다면 Missing File Focused이 더욱 의미가 있을 것이라는 것을 나는 잘 알고 있다.나의 실현은 주로 출력에 부족한 링크에 주목한다.개발자들이 가장 큰 승리를 얻기 위해 먼저 집중할 수 있는 방법을 알게 하는 것이 중요하다.

속도에 주목하다
속도는 항상 좋지만, 이런 상황에서 그것은 아마도 매우 중요한 것일 것이다.저장할 때마다 실행할 수 있도록 빠른 것이 필요합니다.예를 들어 도구가 CI에서 실행되면 속도도 매우 중요하다.대량의 문서를 포함하는 프로젝트에 대해 우리는 문서를 검사하기 위해서만 CI를 차지하는 것을 원하지 않는다.
다행히도 HTML은 성명적이기 때문에 동시에 읽고 분석할 수 있는 훌륭한 분석 언어이다.이것은 파일을 읽을 때 HTML이 처리되었다는 것을 의미할 수도 있습니다.
이런 지식이 있어서 나는 희망으로 가득 차 있다. 그러나 현실은 희망을 가져오지 않는다😅. 내가 필요로 하는 속도를 따라잡을 수 있는 유일한 도구는 Go에서 실현되었다.
대부분의 도구는 HTML의 전체 구문 트리를 만들기 위해 복잡한 파서를 사용하는 것 같습니다.
실제로 링크 검사에 대해서는 id와 href 속성만 알 수 있습니다.
나는 이전에 몇몇 상황에서 sax-wasm을 사용한 적이 있는데, 나는 그것이 흐르는 미디어를 지지한다는 것을 안다.이렇게 하면 금방 되는 거 알아요.🤞!
그러나 우리가 토론하는 속도는 얼마나 빠릅니까?
경험에 따라 저는 작은 사이트(최대 200페이지)에 대한 분석은 1s내에 끝내야 한다고 결정했습니다.
작성/개발 과정에서 매번 저장할 때마다 실행되기 때문에 방해하지 마세요.
중간 규모의 사이트(200-1000페이지)에 대해 더 긴 시간이 필요하다면 합리적이다. 목표를 5초 이내로 정하자.이것은 저장할 때마다 실행하는 것이 아니라 필요에 따라 CI에서만 실행할 수 있는 전환점일 수 있습니다.
결과는 2021년 1월 26일에 수집됩니다.
사이트
페이지
기간
화장실을 열다.조직하다
90
~0.4s
11살.덕부
501
~2.5초
그물 모양의 물건.덕부
830
~3.7초
에스린트.조직하다
3475
~12.4s

NodeJS 생태계의 일부가 되다
JavaScript의 일상적인 업무 프로세스는 대부분 JavaScript에 의해 제어되기 때문에, 만약 내가 그것을 사용하여 초기의 요구에 도달할 수 있다면, 같은 환경에서 유지하고 싶은 것은 매우 자연스러운 것이다.
이외에도 최종 목표는 노드 기반이므로 최소한 NodeJ를 지원해야 하는 대규모 WIP 시스템 Rocket에 통합하는 것입니다.독립형(npx을 통해 사용 가능) 또한 이를 더욱 통용하고 유지보수/테스트가 쉽다.

작은 의존 나무에 주목
JavaScript와 NodeJs 생태계는 매우 활발하고 끊임없이 변화한다.많은 변화/개선이 줄곧 발생하고 있다.보통 따라가기 힘들어요.따라서 작은 의존관계 트리를 가지는 것은 유지보수 부담을 줄이기 때문에 추구할 만한 일이다.추가적인 장점으로, 그것은 그것을 더욱 작고, 더욱 쉽게 끼워 넣을 수 있다. 왜냐하면 필요한 것이 더욱 적기 때문이다.정익위왕👑.

솔루션
앞에서 말한 바와 같이, 나는 스스로 링크 검사기를 실현하였다😅. 지금까지 그것은 나의 모든 요구에 부합되었기 때문에 나는 성공이라고 부른다🎉! on npm을 찾을 수 있습니다.
나는 check-html-links이라고 하는데, 그 구호는 더 이상 체인이나 자산이 없다는 것이다.
현재의 특징은 다음과 같습니다.

추출 id,href,src,srset

의 각 속성 값

wasm 해석기(ax wasm) 사용

html에 대해 흐르는 처리를 하여 성능

획득

파일에 파일 또는 id

이 있는지 확인

부족한 참고 문헌/출처

사용법
최종 html 출력을 검사하기 때문에 정적 사이트 생성기 다음에 실행해야 합니다.

npx check-html-links _site

Github 작업 사용
이 도구에 사용할 수 있는 Github 작업이 만들어졌기 때문에 기존 CI에 쉽게 삽입할 수 있습니다.on the GitHub Marketplace을 찾을 수 있습니다.
다음은 푸시할 때마다 저장소 루트 디렉토리에 있는 _site 폴더의 결과를 확인하는 전체 워크플로우 예입니다.

on: [push]

jobs:
  check_html_links_job:
    runs-on: ubuntu-latest
    name: A job to test check-html-links-action
    steps:
      - uses: actions/checkout@v2
      - name: check-html-links-action step
        id: check-links
        uses: modernweb-dev/check-html-links-action@v1
        with:
          doc-folder: '_site_'

비교
501개의 파일을 검사하는 동시에 11ty-website의 출력과 13개의 부족한 참고 목표(516개의 링크로 사용)를 검사한다.(2021년 1월 17일)
공구.
인쇄물
기간
쓸데없이 길었어
의존 트리
html 링크 검사
38
~2.5초
노트
19
링크 검사기
3000+
~11초
노트
106
하이퍼링크
68
4m 20초
노트
481
htmltest
1000+
~0.7초
가다
-

미래.
기본 기능이 완성되었고 속도도 상당히 빠르다.
작업 항목:

폴더 무시 허용 (cli 매개 변수를 통과할 수 있음)

<base href="/"> 지원

대형 웹 사이트의 속도 향상(여러 개의 해상도를 동시에 실행할 수 있고 1000개 이상의 페이지를 처리할 수 있음)

은 분석 결과에 영구 캐시를 적용합니다(파일이 변경되지 않은 경우 확인 결과는 변경되지 않음 - 모든 링크를 확인함).

속도를 높입니다.

메모리 사용량 검사(개선 공간 표시)

개선 노드api

외부 링크 확인

감사를 드리다check-html-links을 만들어 주셔서 감사합니다.너는 Github에서 코드를 찾을 수 있다.
계속해서 우리를 주목하거나 나의 개인 정보를 주목하라.
피드백에 감사드리며 낙서를 추적할 수 있는 이야기로 만들어 드리겠습니다.
만약 네가 나의 개원 작업이 매우 가치가 있다고 생각한다면, 나는 너에게 나의 개인 자료 Github Sponsor Page을 보여 주고 싶다.또는 Modern Web Open Collective을 통해 저희 팀 전체를 지원할 수 있습니다.
Teslariu Mihai, Unsplash에서 촬영