Add guidance for package maintenance
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 55/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- javascript
- Domain
- documentation
Research direction
Start by reviewing the existing contributor documentation and the linked SemVer guidance, then identify where package-maintenance guidance belongs. Cover the module template, versioning, changelogs, prerelease testing, dependency types, and the local and CI workflows listed in the issue. Done means these topics are documented clearly for package contributors.
Written by the indexing model from the issue text.
Description
Cover topics like:
- Use the module template
- Follow SemVer
- Changelog maintenance
- Testing prerelease builds locally and on CI
- e.g. yarn link or file:// for local, preview builds for CI
- dependencies vs peerDependencies vs devDependencies
Notes:
This message was on Slack and should be included in the guidelines in some way:
PSA: There are two primary ways that we communicate changes we've make to our NPM packages to consumers. Changelogs are one of them, but we also use versions as a coarse indicator as well. I have seen several instances over time where a version for a released package was bumped in a way that either oversells or undersells the changes inside of that release. For instance:
- Bumping the minor part of a version if new functionality was not being added, when only the patch should have been bumped
- Bumping only the patch part of a version when new functionality was added, when the minor should have been bumped
- Not bumping the major part of a version when breaking changes are introduced
As a reminder, we use SemVer to assign new versions for packages. I would recommend everyone read this when they get a chance, especially the "Why Use" section and the FAQ.
- Dominant language
- JavaScript
- Stars
- 87
- Forks
- 43
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from MetaMask/contributor-docs
-
Difficulty 1/5 Under an hour Newbie friendliness 62/100
MetaMask/contributor-docs#164 ·
-
category-documentation github-migration-triaged team-wallet-framework wf-documentation
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
MetaMask/contributor-docs#115 · 1 comment ·
-
issueOpen
Difficulty 5/5 Over a week Newbie friendliness 10/100
MetaMask/contributor-docs#169 ·
-
team-core-platform
Difficulty 4/5 3-5 days Newbie friendliness 45/100
MetaMask/contributor-docs#157 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 15/100
MetaMask/contributor-docs#142 ·
All issues in MetaMask/contributor-docs
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
daisy/a11y-meta-viewer#18 ·
-
good first issue status: needs triaging type: bug version: 2.0
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
medusajs/medusa#17094 · 2 comments ·
Maintainers usually reply within 1 day
-
browser: chrome package: @carbon/react package: styles
Difficulty 1/5 Under an hour Newbie friendliness 92/100
carbon-design-system/carbon#23567 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
clerk/javascript#10033 ·
Maintainers usually reply within 1 day
-
bug client p1
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
vercel/eve#4173 · 2 comments ·
Maintainers usually reply within 1 day