Gathering detailed insights and metrics for @dgilperez/semantic-release-gitmoji
Gathering detailed insights and metrics for @dgilperez/semantic-release-gitmoji
✨🐛💥 A semantic-release plugin for gitmojis. Different from conventional changelog, Gitmoji commits are used to determine a release type and generate release notes.
npm install @dgilperez/semantic-release-gitmoji
Typescript
Module System
Node Version
NPM Version
25.9
Supply Chain
91.9
Quality
67.8
Maintenance
100
Vulnerability
93
License
JavaScript (90.83%)
Handlebars (9.17%)
Total Downloads
932
Last Day
2
Last Week
3
Last Month
6
Last Year
250
118 Commits
1 Forks
1 Branches
1 Contributors
Minified
Minified + Gzipped
Latest Version
1.6.1
Package Id
@dgilperez/semantic-release-gitmoji@1.6.1
Unpacked Size
28.98 kB
Size
9.39 kB
File Count
17
NPM Version
8.18.0
Node Version
18.8.0
Publised On
24 Jan 2023
Cumulative downloads
Total Downloads
Last day
0%
2
Compared to previous day
Last week
200%
3
Compared to previous week
Last month
-14.3%
6
Compared to previous month
Last year
-60.1%
250
Compared to previous year
11
1
✨🐛💥 A semantic-release plugin for gitmojis.
Fork to quickstart issues
Different from conventional changelog, Gitmoji commits are used to determine a release type and generate release notes.
Step | Description |
---|---|
analyzeCommits | Determine the type of release by analyzing commits with Gitmoji. |
generateNotes | Generate release notes for the commits added since the last release with Gitmoji. |
npm install semantic-release-gitmoji -D
The plugin can be configured in the semantic-release configuration file:
1// in ".releaserc.js" or "release.config.js" 2 3const { promisify } = require("util"); 4const dateFormat = require("dateformat"); 5const readFileAsync = promisify(require("fs").readFile); 6 7// Given a `const` variable `TEMPLATE_DIR` which points to "<semantic-release-gitmoji>/lib/assets/templates" 8 9// the *.hbs template and partials should be passed as strings of contents 10const template = readFileAsync(path.join(TEMPLATE_DIR, "default-template.hbs")); 11const commitTemplate = readFileAsync( 12 path.join(TEMPLATE_DIR, "commit-template.hbs") 13); 14 15module.exports = { 16 plugins: [ 17 [ 18 "semantic-release-gitmoji", 19 { 20 releaseRules: { 21 major: [":boom:"], 22 minor: [":sparkles:"], 23 patch: [":bug:", ":ambulance:", ":lock:"], 24 }, 25 releaseNotes: { 26 template, 27 partials: { commitTemplate }, 28 helpers: { 29 datetime: function (format = "UTC:yyyy-mm-dd") { 30 return dateFormat(new Date(), format); 31 }, 32 }, 33 issueResolution: { 34 template: "{baseUrl}/{owner}/{repo}/issues/{ref}", 35 baseUrl: "https://github.com", 36 source: "github.com", 37 removeFromCommit: false, 38 regex: /#\d+/g, 39 }, 40 }, 41 }, 42 ], 43 "@semantic-release/github", 44 "@semantic-release/npm", 45 ], 46};
This configuration is the same semantic as the default configuration of semantic-release-gitmoji
.
semantic-release-gitmoji
should be used in place of both @semantic-release/commit-analyzer
and @semantic-release/release-notes-generator
since the both plugins parse commits following the conventional changelog while this plugin requires Gitmoji commits.
It is recommended to write the configuration in a javascript file since templates are required to be string
s of their contents.
1interface SemanticReleaseGitmojiOptions { 2 releaseRules?: ReleaseRules; 3 releaseNotes?: ReleaseNotesOptions; 4}
The ReleaseRules
is a map from a release type to a set of emojis.
1interface ReleaseRules { 2 major?: Array<Emoji> | EmojiArrayModifier; 3 premajor?: Array<Emoji> | EmojiArrayModifier; 4 minor?: Array<Emoji> | EmojiArrayModifier; 5 preminor?: Array<Emoji> | EmojiArrayModifier; 6 patch?: Array<Emoji> | EmojiArrayModifier; 7 prepatch?: Array<Emoji> | EmojiArrayModifier; 8 prerelease?: Array<Emoji> | EmojiArrayModifier; 9}
Emoji
is a string of valid GitHub emoji markup (e.g. ":boom:"
, ":collision:"
) or raw emoji characters (e.g. "💥"
).
No need to worry about which format to use since this plugin handles it for you!
See https://github.com/omnidan/node-emoji for more information about emojis.
1type Emoji = string;
1interface EmojiArrayModifier { 2 include?: Array<Emoji>; 3 exclude?: Array<Emoji>; 4}
ReleaseNotesOptions
defines how to render the release notes from a given set of Gitmoji commits.
All templates file are compiled and renderered by handlebars
, therefore you may need to get familiar with the .hbs
format before starting to customize your own templates.
semver
is a boolean to define if releaseNotes should be based on Gitmoji only or on key semver associated to gitmoji used in commit to determine the next release tag.
partials
is a map from the partial name to the content of the partial template.
helpers
is a map from the helper name to the helper function. There is already a default helper datetime
which takes a format string as the first argument and return a formatted current timestamp. See npm/dateformat for more information about how to format a timestamp and see the default template as an example.
Besides, You are allowed to provide helpers with the same names to override default helpers.
issueResolution
defines how issues are resolved to. The default and the only supported source currently is github.com
, or you can provide your own issueResolution.template
to override the default resolution to GitHub.
There are five variables that can be used in issueResolution.template
:
baseUrl
owner
repo
ref
, which is the numeric ID of issueissue
, which is the full issue1interface ReleaseNotesOptions { 2 template?: TemplateContent; 3 semver?: Boolean; 4 partials?: Record<string, TemplateContent>; 5 helpers?: Record<string, Function>; 6 issueResolution?: { 7 template?: string; 8 baseUrl?: string; 9 source?: "github.com" | null; // currently only GitHub is supported, PR welcome :) 10 regex?: RegExp; // regex to match the issue(s). If not provided, will find issues thanks to [issue-regex](https://www.npmjs.com/package/issue-regex) 11 removeFromCommit?: boolean; // if true, will remove found issue(s) from commit name 12 }; 13}
1type TemplateContent = string | Buffer | Promise<string> | Promise<Buffer>;
The context for templates is inherited from semantic-release
context with some modifications such as owner
, repo
and compareUrl
.
commits
is a map from Emoji
(don't worry about the format) to a list of extended commits.
Values of commits
are extended to contain more information related to Gitmoji. See CommitContext
1interface TemplateContext { 2 owner: string; 3 repo: string; 4 source: string; 5 commits: Record<string, Array<CommitContext>>; 6 lastRelease: { 7 gitHead: string; 8 version: string; 9 gitTag: string; 10 }; 11 nextRelease: { 12 type: string; 13 gitHead: string; 14 version: string; 15 gitTag: string; 16 }; 17 compareUrl: string; 18}
CommitContext
is extended from SemanticReleaseCommitObj
.
Note that emojis at the beginning of message
and subject
are trimmed, which are the same emoji in gitmoji
.
gitmoji
is a raw emoji since an emoji may have more than one GitHub emoji markup representation, e.g. ":boom:"
and ":collision:"
both represent for th emoji, "💥"
.
1interface CommitContext extends SemanticReleaseCommitObj { 2 message: string; 3 subject: string; 4 owner: string; 5 repo: string; 6 source: string; 7 gitmoji: string; 8 issues: Array<IssueLink>; 9 wip: Array<CommitContext>; 10}
1interface IssueLink { 2 text: string; 3 link: string; 4}
Assume you file an issue (e.g. #1
) to implement a new feature, then you make 3 commits as belows (the toppest is the latest).
✨ Add a new feature.\n\n#1
🚧 Implement part B.\n\n#1
🚧 Implement part A.\n\n#1
The ✨ commit will be the final commit composed of two 🚧 commits. They are linked together via #1
in the commit message.
Therefore the commits
of the template context will be as follows.
1{ 2 "commits": { 3 "sparkles": [ 4 { 5 "message": "Add a new feature.\n\n#1", 6 "subject": "Add a new feature.", 7 "body": "#1", 8 "gitmoji": "✨", 9 "// repo": "", 10 "// owner": "", 11 "source": "github.com", 12 "issues": [ 13 { 14 "text": "#1", 15 "// link": "" 16 } 17 ], 18 19 "wip": [ 20 { 21 "message": "Implement part B.\n\n#1", 22 "subject": "Implement part B.", 23 "body": "#1", 24 "gitmoji": "🚧", 25 "// repo": "", 26 "// owner": "", 27 "source": "github.com", 28 "issues": [ 29 { 30 "text": "#1", 31 "// link": "" 32 } 33 ] 34 }, 35 { 36 "message": "Implement part A.\n\n#1", 37 "subject": "Implement part A.", 38 "body": "#1", 39 "gitmoji": "🚧", 40 "// repo": "", 41 "// owner": "", 42 "source": "github.com", 43 "issues": [ 44 { 45 "text": "#1", 46 "// link": "" 47 } 48 ] 49 } 50 ] 51 } 52 ], 53 54 "// other gitmojis": "" 55 } 56}
Beside using issue number to link commits, the following syntax is also available to link commits together.
wip#{target_name}
While target_name
is an identifier for those progressive commits, for example, wip#feature-A
.
target_name
can contain numbers, letters (both cases), _
or -
.target_name
should not start with _
or -
.PRs are welcome.
Before sending PRs, please follow the steps below.
dev
.npm run lint
and ensure you pass the linter.npm test
and ensure nothing broken.
dev
and wait for reviews.Thanks for all lovers and contributers of this project!
No vulnerabilities found.
No security vulnerabilities found.