clerk-community / elysia-clerk
Unofficial Clerk plugin for Elysia.js.
clerk-community/elysia-clerk має індекс здоров’я 51 зі 100, що відповідає смузі «Помірний». Найвищий показник — Vitality (66/100), найнижчий — Security (40/100). Останнє оновлення було 40 днів тому. Більшість нещодавньої роботи виконує один учасник.
Індекс здоров'я програмного забезпечення
Метрики згруповано у зважені категорії на шкалі 1–100. Загальна оцінка починається як їхнє зважене середнє, відкаліброване за розподілом публічного реєстру, тож діапазони мають перцентильний зміст; коли публічні дані активують Політику юрисдикцій високого ризику, рейтинг коригується й отримує верхню межу 34 («У зоні ризику»).
Профіль оцінок
Кожна вісь — окрема категорія. Форма важить більше, ніж середнє: здоровий об'єкт заповнює всю фігуру, тоді як профіль із піками та провалами означає, що сила в одному вимірі маскує ризик в іншому.
Зважений загальний бал 51 калібровано до 51 за шкалою опублікованого індексу (калібрування реєстру 2026-08-02).
Власність
За цим репозиторієм стоїть організація — спільна, підзвітна опіка, здатна пережити будь-якого окремого мейнтейнера.
Пакетні екосистеми
| Реєстр | Пакет | Версія | Завантажень / міс | Версії | Остання публікація | Теги |
|---|---|---|---|---|---|---|
| npm | elysia-clerkвказує на інший репозиторій — не оцінюється | 1.0.2 | 3 451 | 51 | 55 днів тому | authauthenticationbunclerkjwtpasswordlesssessiontypescript |
Метрики за категоріями
Життєздатність
Чи живий проєкт — чи пишеться код і чи виходять релізи?
Активність розробки
Як обчислюється оцінка
| 18/36 | Свіжість push — останній push 40 дн. тому |
| 9/36 | Ритм комітів — 13/52 тижнів із комітами |
| 17/18 | Обсяг комітів — 77 комітів за останній рік |
| 0/10 | OpenSSF Scorecard: Maintained — немає даних |
Використані вхідні дані
| commits_last_year | 77 |
| human_commit_share | 0,76 |
| days_since_last_push | 40 |
| active_weeks_last_year | 13 |
Дисципліна релізів
Як обчислюється оцінка
| 27/27 | Випускає релізи — опубліковано 37 релізів |
| 36/36 | Свіжість релізів — останній реліз 55 дн. тому |
| 19.8/27 | Ритм релізів — реліз кожні ~45,6 дн. |
| 0/10 | OpenSSF Scorecard: Signed-Releases — немає даних |
Використані вхідні дані
| releases_count | 37 |
| latest_release_tag | v1.0.2 |
| releases_from_tags | ні |
| days_since_latest_release | 55 |
| mean_days_between_releases | 45,6 |
Спільнота та впровадження
Чи має проєкт користувачів, завантаження, увагу та влаштовані умови для контриб’юторів?
Популярність і впровадження
Як обчислюється оцінка
| 32.8/60 | Зірки — 106 зірок |
| 6.5/25 | Форки — 7 форків |
| 0/15 | Спостерігачі — 2 спостерігачів |
Використані вхідні дані
| forks | 7 |
| stars | 106 |
| watchers | 2 |
| growth_state | unverified |
| growth_factor_pct | 100 |
| growth_unverified_reason | no_history |
Здоров'я спільноти
Як обчислюється оцінка
| 22.5/22.5 | README |
| 22.5/22.5 | Ліцензія — визнана ліцензія (MIT) |
| 0/18 | Настанови CONTRIBUTING |
| 0/13.5 | Кодекс поведінки |
| 0/7.2 | Шаблон issue |
| 0/6.3 | Шаблон PR |
Використані вхідні дані
| has_readme | так |
| has_license | так |
| readme_badges | 0 |
| has_contributing | ні |
| has_issue_template | ні |
| has_code_of_conduct | ні |
| readme_badge_services | — |
| has_pull_request_template | ні |
Сталість та врядування
Чи переживе проєкт своїх людей — бас-фактор, реактивність, хто за ним стоїть і як супроводжуються пакети?
Стійкість мейнтейнерів (бас-фактор)
Як обчислюється оцінка
| 9/54 | Бас-фактор — на 1 контриб’ютор(ів) припадає половина всіх комітів |
| 0.1/22.5 | Розподіл комітів — головний контриб’ютор — автор 100% комітів |
| 2.7/13.5 | Широта контриб’юторів — 2 контриб’юторів |
| 0/10 | OpenSSF Scorecard: Contributors — немає даних |
Використані вхідні дані
| bus_factor | 1 |
| contributors_sampled | 2 |
| top_contributor_share | 0,997 |
Реактивність на issue та PR
Як обчислюється оцінка
| 31.5/42 | Вирішення issue — закрито 75% issue |
| 23.9/30 | Прийняття PR — злито 94/118 вирішених PR |
| 0/13 | Newcomer PR acceptance — за 30 дн. не вирішено жодного PR від новачка |
| 0/15 | OpenSSF Scorecard: Code-Review — немає даних |
Використані вхідні дані
| merged_prs | 94 |
| open_issues | 4 |
| closed_issues | 12 |
| prs_merged_7d | 0 |
| prs_decided_7d | 0 |
| prs_merged_30d | 0 |
| prs_decided_30d | 0 |
| issue_closed_ratio | 0,75 |
| closed_unmerged_prs | 24 |
| first_time_authors_30d | 0 |
| first_time_prs_merged_30d | 0 |
| first_time_prs_decided_30d | 0 |
Власність та опіка
Як обчислюється оцінка
| 30/30 | Підтримка власника — у власності організації |
| 0/20 | Верифікований домен |
| 3.4/25 | Охоплення власника — 2 підписників у clerk-community |
| 11.6/25 | Послужний список — 4 публічних репозиторіїв, вік облікового запису ~3 р. |
Використані вхідні дані
| followers | 2 |
| owner_type | Organization |
| is_verified | ні |
| owner_login | clerk-community |
| public_repos | 4 |
| account_age_days | 1 195 |
Інженерна якість
Чи наявні базові інженерні практики та документація?
Інженерні практики
Як обчислюється оцінка
| 24/24 | Процеси CI — 4 процес(ів) CI |
| 24/24 | Наявні тести |
| 0/16 | Конфігурація лінтера |
| 0/9.6 | Pre-commit-хуки |
| 0/6.4 | .editorconfig |
| 0/20 | OpenSSF Scorecard: CI-Tests — немає даних |
Використані вхідні дані
| has_ci | так |
| has_tests | так |
| has_editorconfig | ні |
| has_linter_config | ні |
| has_precommit_config | ні |
Документація
Як обчислюється оцінка
| 30/30 | README |
| 0/25 | Каталог документації |
| 0/15 | Сайт документації / домашня сторінка |
| 10/10 | Опис репозиторію |
| 10/10 | Теми — 2 тем |
| 0/10 | Wiki |
Використані вхідні дані
| topics | auth, bun |
| has_wiki | ні |
| homepage | — |
| docs_site | — |
| has_readme | так |
| has_docs_dir | ні |
| has_description | так |
Безпека
Чи міцні видимі практики безпеки й ланцюга постачання, без непослабленої пов’язаності з юрисдикціями високого ризику?
Стан безпеки
Як обчислюється оцінка
| 0/30 | Політика безпеки (SECURITY.md) |
| 25/25 | Конфігурація Dependabot |
| 0/25 | Файли фіксації залежностей |
| 0/20 | Процес CodeQL |
Використані вхідні дані
| source | file_signals |
| lockfiles | — |
| manifests | package.json |
| has_codeql_workflow | ні |
| has_security_policy | ні |
| has_dependabot_config | так |
Сповіщення про залежності
Як обчислюється оцінка
| 35/35 | Прямі залежності без відомих сповіщень — жодна пряма залежність не має відомих сповіщень |
| 25/25 | Непрямі залежності без відомих сповіщень — жодна непряма залежність не має відомих сповіщень |
| 0/40 | Немає задавнених сповіщень — жодне сповіщення не має дати публікації |
Використані вхідні дані
| source | osv |
| advisories | 0 |
| affected_packages | 0 |
| assessed_packages | 10 |
| unassessed_packages | 0 |
| affected_by_severity | none |
| direct_affected_packages | 0 |
Готовність до ШІ
Наскільки репозиторій оснащений для розробки та супроводу за участі ШІ-агентів? Має свідомо малу вагу (4%): агентний інструментарій — реальний сигнал супроводу, але репозиторій без нього все одно може отримати 100/100.
Контекст і настанови для агентів
Як обчислюється оцінка
| 0/45 | Інструкції для агентів — немає CLAUDE.md / AGENTS.md / правил редактора |
| 15/15 | Машиночитана документація (llms.txt) — llms.txt опубліковано на сайті проєкту (https://clerk.com/llms-full.txt) |
| 40/40 | Читабельна історія комітів — намір зазначено у 68 з 76 людських комітів (структурований заголовок або пояснювальний текст) |
Використані вхідні дані
| has_llms_txt | так |
| llms_txt_url | https://clerk.com/llms-full.txt |
| legible_history_share | 0,895 |
| agent_instruction_files | — |
| agent_instruction_max_bytes | — |
Як обчислюється оцінка
| 0/18 | Розгортання однією командою |
| 22/22 | Автоматизовані тести |
| 0/11 | Конфігурація лінтера / форматера |
| 11/11 | Статична перевірка типів — tsconfig.json |
| 0/10 | Відтворюване середовище |
| 0/10 | Підтверджена практика роботи з агентами — серед останніх 100 комітів немає створених агентом |
| 8/8 | Автоматизоване супроводження — 16 з останніх 100 комітів — автоматичні оновлення залежностей |
| 0/10 | OpenSSF Scorecard: Pinned-Dependencies — немає даних |
Використані вхідні дані
| has_nix | ні |
| has_tests | так |
| lockfiles | — |
| has_dockerfile | ні |
| typed_language | так |
| bootstrap_files | — |
| has_devcontainer | ні |
| has_linter_config | ні |
| typecheck_configs | tsconfig.json |
| agent_commit_share | 0 |
| toolchain_manifests | — |
| dependency_bot_commit_share | 0,16 |
Читабельність коду для моделей
Як обчислюється оцінка
| 45/45 | Типізований код — TypeScript (статично типізована) |
| 55/55 | Керовані розміри файлів — 0/13 файлів вихідного коду понад 60 КБ |
Використані вхідні дані
| primary_language | TypeScript |
| largest_source_bytes | 6 983 |
| source_files_sampled | 13 |
| oversized_source_files | 0 |
Ключові факти
Попередження щодо збору даних
- Star history unavailable: GitHub GraphQL error: Resource not accessible by personal access token
- npm package 'elysia-clerk' points at a different repository (https://github.com/wobsoriano/elysia-clerk); excluded from ecosystem scoring
- OpenSSF Scorecard did not return a usable result (exit code 0; Skipping github.com/clerk-community/elysia-clerk: run: RepoClient.LocalPath: error during tarballHandler.setup: internal error: handler.httpClient.Do: Get "https://codeload.github.com/clerk-community/elysia-clerk/legacy.tar.gz/refs/heads/main": internal error: innerTransport.RoundTrip: internal error: innerTransport.RoundTrip: error in HTTP: dial tcp: lookup codeload.github.com on 127.0.0.11:53: server misbehaving); skipping Scorecard checks
Докладніше
Історія зірок і форків 0 ★ / 7 ⇿
Коли додано кожну зірку й форк — зібрано з GitHub і згруповано за днями. Кумулятивне зростання розміщено просто над денними додаваннями, з яких воно складається, тож їх видно одне проти одного: рівномірне органічне накопичення виглядає зовсім інакше, ніж різкий короткочасний сплеск. Там, де цю різницю можна виміряти, її подано як автентичність росту.
Кожна точка охоплює 3 днів.
Прямі залежності 2
| Реєстр | Пакет | Обмеження версії | Маніфест |
|---|---|---|---|
| npm | @clerk/backend | ^3.13.0 | package.json |
| npm | @clerk/shared | ^4.25.7 | package.json |
Усі залежності 9
Повний розв'язаний набір залежностей із графа залежностей GitHub: 2 прямих і 7 непрямих (транзитивних) пакетів. Транзитивне замикання є повним, коли в репозиторії закомічено lockfile.
| Реєстр | Пакет | Версія | Зв'язок |
|---|---|---|---|
| npm | @clerk/backend | ^3.13.0 | пряма |
| npm | @clerk/shared | ^4.25.7 | пряма |
| npm | @arethetypeswrong/cli | ^0.18.2 | непряма |
| npm | @changesets/cli | ^2.27.10 | непряма |
| npm | @elysiajs/eden | ^1.4.8 | непряма |
| npm | @elysiajs/html | ^1.4.0 | непряма |
| npm | elysia | ^1.4.28 | непряма |
| npm | typescript | 6.0.2 | непряма |
| npm | vite-plus | ^0.1.14 | непряма |
Сповіщення про залежності 0
Встановлення npm:elysia-clerk@1.0.2 тягне 10 пакетів, прямих і транзитивних: 0 мають відомі сповіщення, з них 0 — прямі залежності.
Жодне відоме сповіщення не стосується оцінених залежностей.
Сповіщення означає, що версія, записана в графі залежностей, потрапляє в уражений діапазон. Досяжність не аналізується, а граф містить піниї розробки й тестування — знахідка може стосуватися інструментів, а не поставленого коду.
Звіт у форматі JSON машиночитний
Зворотний зв’язок
Помітили щось хибне у цьому звіті або маєте чим поділитися? Неправильні вимірювання, непомічені інструменти, ідеї, запитання — усе доречно. Кожне повідомлення читається й отримує відповідь.
Оцінки — це сигнали, а не гарантії. Вони відображають публічно видимі практики на GitHub — це не аудит коду й не гарантія безпеки.
Відсутні дані виключаються, а ваги перенормовуються — нуль за відсутність ніколи не ставиться. Методологія версіонована й відкрита: метрики v2.10.0, схема v0.34.0 — повна методологія · вікі метрик.
Як окремий результат виглядає на тлі всього реєстру: сукупна статистика — npm.