For further actions, you may consider blocking this person and/or reporting abuse
Read next
Mastering Bash: Essential Commands for Everyday Use
Oliver Bennet -
Did You Have a Mentor, and Did It Help You?
Yan Levin -
How to Extract LoRA from FLUX Fine Tuning Full Tutorial + Comparison Between Fine Tuning Extraction vs LoRA Training
Furkan Gözükara -
Linux, I Choose You! 🐧
Jimmy McBride -
Top comments (2)
Build status and test coverage % almost always; @jcowie mentioned a code quality metric but I think reducing so many factors into a single number loses most of the helpful information. Minimum Node engine version if appropriate, and download stats if it's got any traction.
Git Release
To ensure the latest release tag matches the latest release published to NPM. Also, it'll be behind if I forgot to fill out the release notes.
NPM Release
To ensure the published version is up-to-date and provide a link to the package on NPM.
License
My packages appear on multiple platforms. It's good to have the license visible on the README.md
Lastest Status
GitHub Actions status for the master branch. Good to see if the checks (lint, test, types) are failing.
Release Status
GitHub Actions status for the last published release. Everything undergoes extensive checks prior to release so this should never fail. But it's always good to have visibility on the status in case it does.