Forem: azu

JSer.info 15th Anniversary: Looking Back at 15 Years of JavaScript

azu — Fri, 16 Jan 2026 11:25:00 +0000

This article is a translation of the Japanese article: JSer.info 15周年: 15年間のJavaScriptを振り返る

What is JSer.info?

JSer.info is a weekly JavaScript newsletter that has been running since January 16, 2011. It curates and summarizes the latest JavaScript-related articles, libraries, and tools from around the web, delivering them to readers every week. The goal is to "organize JavaScript information and deliver it accurately."

JSer.info, which started on January 16, 2011, celebrates its 15th anniversary on January 16, 2026 🎉

Over 15 years, JSer.info has published 820 articles and introduced 13,606 sites/articles/libraries. Weekly updates have continued for 15 years straight.

In this article, we'll look back at JSer.info's data over 15 years and see how the JavaScript ecosystem has changed.

Note that the data in this article reflects trends in articles introduced on JSer.info and doesn't represent the entire JavaScript ecosystem.
Also, please note that JSer.info's posting frequency decreased in 2024-2025, which affects the 2025 data showing a declining trend.

Basic Statistics Over 15 Years

Item	Value
Total Posts	820
Total Articles Introduced	13,606
Operating Period	January 2011 - January 2026 (15 years)
Average Update Frequency	Weekly

Looking at articles introduced per year, the peak was 1,269 in 2013, and recent years have stabilized around 600-700. Meanwhile, the average length of article descriptions has roughly doubled over 15 years, showing a shift from "quantity to quality."

Year	Articles Introduced	Posts	Per Post	Avg. Description Length
2011	915	65	14.1	62 chars
2013	1,269	57	22.3	58 chars
2017	1,068	54	19.8	79 chars
2019	790	53	14.9	90 chars
2021	789	53	14.9	101 chars
2025	552	41	13.5	108 chars

Also, the posting pace dropped slightly in 2025, reducing the number of posts.
Therefore, please note that the subsequent data also shows a declining trend in 2025.

Changes in Information Sources: From Personal Blogs to Official Documentation

The most significant change over 15 years is the composition of information sources.

Early Period (2011-2013) Main Sources

github.com (327)
d.hatena.ne.jp (154)
slideshare.net (147)
amazon.co.jp (98)
amazon.com (83)

Middle Period (2017-2019) Main Sources

github.com (828)
medium.com (134)
developers.google.com (103)
webkit.org (69)
nodejs.org (64)

Late Period (2023-2025) Main Sources

github.com (568)
nodejs.org (98)
bun.sh (62)
zenn.dev (56)
developer.chrome.com (55)

While GitHub has consistently been the largest information source, the surrounding landscape has changed significantly.

In the early period, Hatena Diary, SlideShare, and Amazon (books) ranked high. It was an era when personal blogs, conference slides, and books were primary information sources.

In the middle period, Medium became prominent, and browser vendors' official documentation/blogs (like developers.google.com and webkit.org) entered the top ranks. Personal blog platforms shifted from Hatena to Medium, while primary information from browser vendors became more valued.

In the late period, official documentation/blogs (nodejs.org, developer.chrome.com, bun.sh) and zenn.dev rank high. Medium has disappeared, and direct access to primary sources has increased.

Changes in Content Types

Type	2011-2013	2014-2016	2017-2019	2020-2022	2023-2025
Release Notes	560	750	862	937	986
Tutorial Articles	719	692	813	617	526
Libraries/Tools	371	599	446	397	191
Slides/Videos	292	309	170	60	49
Book-related	192	203	135	73	45
Tutorials	97	154	93	33	14

Release notes have consistently increased. Meanwhile, learning content like slides/videos, books, and tutorials has decreased. This reflects how official documentation has become richer and GitHub release notes have become the center of information sharing, reducing the introduction of conference slides and books.

Evolution of Japanese Blog Platforms

Japanese tech blogs introduced on JSer.info have seen major platform shifts over 15 years.

Year	Hatena	Qiita	Zenn
2011	92	0	0
2014	29	19	0
2016	10	45	0
2020	3	4	3
2021	1	1	22
2024	2	1	24

The platform flow has been Hatena Diary/Hatena Blog → Qiita → Zenn.

However, the proportion of Japanese sources overall has gradually decreased, stabilizing around 5%.
(This is based on titles only, so the actual percentage might be slightly higher.)

Year	Japanese Sources	Total	Percentage
2011	203	915	22.2%
2012	194	1126	17.2%
2013	150	1269	11.8%
2014	114	1147	9.9%
2015	80	1043	7.7%
2016	93	1078	8.6%
2017	67	1068	6.3%
2018	64	921	6.9%
2019	26	790	3.3%
2020	25	810	3.1%
2021	43	789	5.4%
2022	33	712	4.6%
2023	42	737	5.7%
2024	44	638	6.9%
2025	26	552	4.7%

This isn't because JSer.info intentionally avoids Japanese sources, but rather reflects that primary JavaScript information sources are almost entirely in English. Browser vendors, official sites/projects, and maintainers of major libraries almost always publish information in English.

Technology Trend Changes

UI Frameworks: jQuery → Angular → React

Year	jQuery	Angular	React	Vue
2011	109	1	0	0
2013	86	44	6	0
2014	35	49	52	11
2015	29	30	103	10
2017	7	34	153	28
2019	9	9	84	20
2021	8	6	84	23
2025	1	4	82	4

jQuery was most mentioned in 2011, Angular/React/Vue started increasing around 2013/2014, and React grew significantly in 2015. React peaked at 153 mentions in 2017, then entered a stable period.

In 2025, React mentions are about half of the peak, indicating that React itself has matured and there's less weekly news to cover.

Build Tools: webpack → Vite

Year	webpack	Rollup	esbuild	Vite
2016	33	2	0	0
2017	43	8	0	0
2020	26	7	5	1
2022	11	3	9	28
2023	13	10	16	36
2025	8	2	6	23

webpack peaked in 2017 and was frequently discussed until 2020.
Meanwhile, esbuild emerged in 2020, and by 2022, Vite mentions surpassed webpack.

Since esbuild's emergence, JSer.info has introduced more tools written in Rust and Go. This reflects a change in expectations around performance, breaking the assumption that "JavaScript tools are written in JavaScript."

Runtimes: From Node.js Dominance to Diversification

Year	Deno	Bun
2020	13	0
2021	21	1
2022	21	5
2023	19	27
2024	18	26

Deno 1.0 was released in 2020, and Bun emerged in 2022. The era transitioned from Node.js dominance to multiple competing runtimes.

Particularly Bun, with regular releases since its 1.0 release in 2023, has been frequently introduced on JSer.info.

Technologies with Changed Mentions on JSer.info

Technologies That Disappeared (2011-2013 → 2023-2025)

Technology	Early	Late
Backbone.js	75	0
CoffeeScript	71	0
AMD/RequireJS	74	3
Grunt	49	0
PhantomJS	37	0
Bower	13	0

These technologies were widely used at the time but are no longer covered on JSer.info.

Backbone.js and CoffeeScript were frequently introduced around 2011-2012. AMD and RequireJS pioneered module systems but completed their role with ES Modules standardization. Grunt/Gulp were replaced by npm scripts and build tools, and PhantomJS was superseded by Puppeteer/Playwright.

Technologies with Increased Mentions

Technology	Early	Late
ESM/import	2	117
Rust	1	40
WebAssembly	0	51
monorepo	0	14

ECMAScript Modules were specified in ES2015, but became practically usable in both browsers and Node.js after 2020.

Rust mentions relate to toolchains like SWC/Rspack/Biome/OxC. Performance-critical parts of the JavaScript ecosystem are increasingly written in Rust or Go.
In 2025, TypeScript compiler itself was announced to be rewritten in Go.

WebAssembly was announced in 2015, and JSer.info mentions increased around 2017. While the monorepo concept existed long before, it gained attention in the JavaScript ecosystem after Lerna (2016) and npm/yarn workspaces.
Now, package managers like npm/yarn/pnpm officially support monorepos.

Changes in Cross-Cutting Topics

Let's look at the trends of technology-agnostic, cross-cutting topics.

Year	Types	Testing	Performance	Security	a11y
2011	30	46	27	10	6
2014	52	87	58	14	9
2017	108	86	93	15	15
2020	123	44	80	13	16
2021	129	59	64	28	17
2025	88	47	42	15	23

Types (TypeScript) mentions peaked in 2021 (129) and have since declined. This is likely because TypeScript has become "standard," making "using TypeScript" itself less newsworthy.

Testing mentions peaked in 2014 (87). This was when many test frameworks like Jasmine, Mocha, and Karma were competing, and JSer.info frequently covered them. Now they've converged to Jest, Vitest, Playwright, etc.

Performance mentions peaked in 2017 (93). This was when JSer.info frequently covered webpack optimization, Tree Shaking, and code splitting.

a11y (Accessibility) has consistently increased, growing from 6 to 23 mentions—about 4x.

Changes in Information Source Types

We classified article sources into "Official (Project/Documentation)," "GitHub," and "Personal Blogs."

Source	2011-2013	2014-2016	2017-2019	2020-2022	2023-2025
Official	204	294	467	471	479
GitHub	506	1,015	910	903	596
Personal Blogs	213	194	141	76	70

Official: Official sites/documentation like nodejs.org, webkit.org, reactjs.org, eslint.org
GitHub: github.com, github.io
Personal Blogs: Hatena, Qiita, Zenn, medium.com/@personal, etc.

In comparison, in 2011-2013, personal blogs and official sources were almost equal (213 vs 204), but in 2023-2025, official blogs/documentation is about 7x personal blogs (479 vs 70). As official documentation and project sites have enriched their information sharing, JSer.info's featured sources have become centered on official sites.

Changes in Development Practices

Topics related to development methods have also changed.

Practice	2011-2013	2017-2019	2023-2025
CI/CD	31	56	67
Migration	10	32	56
RFC/Proposal	2	73	45
Breaking Change	3	15	17

Increased RFC/Proposal mentions reflect ECMAScript adopting the Stage system in ES2015, making Proposals more frequently introduced, and more libraries/frameworks adopting RFC processes.

Increased Migration mentions indicate ecosystem maturity. "How to update existing codebases" has become an important theme—migration to new technologies, major version upgrades, and legacy code renewal.

Summary of 15 Years of Change

Here's a summary of changes visible from JSer.info's 15 years of data.

Changes to JSer.info Itself

JSer.info itself has changed over 15 years.

Technical Changes

2014: Migrated from Tumblr to GitHub Pages
2015: Realtime JSer.info launched
2016: HTTPS enabled, Ping feature added
2021: JSer.info Policy published
2023: JSer.info Watch List published
2025: MCP writing assistance, AI-generated headlines introduced

Operational Changes

Weekly updates maintained for 15 years
Workflow built entirely on GitHub
Introduced automatic categorization, auto-tagging, and headline generation
Article posting via postem
Korean version translation (thanks to @uyeong, @rewrite0w0, and @Serzhul)

Progress on the "Make It Replaceable" Goal

In JSer.info 11th Anniversary, we set a goal to "make it replaceable by 2025." While complete replaceability hasn't been achieved, the update workflow has changed significantly through AI utilization.

JSer.info Update Flow 2025 - From YAPC::Fukuoka 2025 presentation

In About JSer.info, we wrote "minimizing the burden on me for updates and enabling smooth operation is key to continuity." Current JSer.info has automated many parts from information gathering to PR creation, tagging, grouping, and headline generation. Human focus has shifted to information judgment—what to introduce and how to communicate it.
Boring tasks are automated, allowing concentration on the valuable part: judgment.

For details, see the YAPC::Fukuoka 2025 presentation.

About 2025 Update Frequency

Update frequency has dropped slightly in 2025. Analyzing personal bookmarks (input for information gathering), we've identified some causes.

Year	Bookmarks	Posts	Post Interval
2021	2,862	53	6.9 days
2023	2,373	53	6.9 days
2025	1,033	41	8.9 days

Bookmarks (input) have decreased 64% from the 2021 peak. Meanwhile, the bookmark-to-article rate has more than doubled. In 2021, 4 bookmarks led to 1 article; in 2025, 2 bookmarks lead to 1 article. As a result, while input decreased 64%, posts only decreased 23%.

The cause of decrease seems to be that while I read articles, the burden of writing descriptions during bookmarking causes some to be missed.
Now that we have numerical data, we hope to track and improve this.
Recently, we've been adding Claude integration and other bookmark assistance features to tools like postem, so we expect improvements.

Also, I've been building an RSS reader recently, allowing JSer.info's entire information system—from RSS to collection to judgment to publication—to run on code I wrote myself.

General flow of JSer.info's information system:

RSS Feeds → Collection → Judgment → Publication

YAPC::Fukuoka 2025 presentation

This should make it technically easier to remove friction points that existed before.

Conclusion

JSer.info started on January 16, 2011, and 15 years have passed.

15 years ago, JavaScript was in the era of jQuery (jQuery celebrated its 20th anniversary on January 14, 2026!) and Backbone.js/CoffeeScript. Now React, TypeScript, and Vite are frequently featured, and runtimes other than Node.js are viable options.

The information sources featured on JSer.info have also changed. From conference slides and books to official documentation and GitHub release notes.

In the ever-changing JavaScript ecosystem, we hope JSer.info has fulfilled its role of "organizing JavaScript information and delivering it accurately."

For opinions and feedback about this article or JSer.info, please share at:

X/Twitter: #jserinfo
JSer.info Slack

Thank you to everyone who has been reading for 15 years and those who have supported us!

JSer.info Sponsors

We thank those who support JSer.info through GitHub Sponsors.
Special thanks to Cybozu, Inc. for their long-term support.

GitHub Sponsors

My GitHub Sponsors Revenue @ 2023

azu — Tue, 26 Dec 2023 11:05:48 +0000

I summarized the income from GitHub Sponsors in 2023.
For the results of last year (2022), see the following article.

My GitHub Sponsors Revenue @ 2022 - DEV Community

GitHub Sponsors is a system that mainly supports open source activities financially.

GitHub Sponsors supports individuals and organizations, but here I summarize GitHub Sponsors for individuals.
My GitHub Sponsors is published on the following page.

Sponsor @azu on GitHub Sponsors

The reason for publishing this article is to get people who are doing open source activities and people who support open source activities interested in financial support systems such as GitHub Sponsors.
Personally, I think it is important that people who use open source can choose to pay for it.

If you are interested in supporting open source, please consider using GitHub Sponsors.

Sponsoring open source contributors - GitHub Docs

Types of open source activities

My open source activities are mainly as follows.

Software development: textlint, Secretlint, HonKit and other development and maintenance.
Web service development: philan.net, Komesan, Irodr, etc.
Blogs: Posting on JSer.info and ECMAScript Daily blogs
Books: Writing for JavaScript Primer and JavaScript Promise book in Japanese

Basically, I do it as a hobby.

Amount of income

There are also two types of support options for GitHub Sponsors: Monthly and One-time.
The amounts listed here include both amounts.
The total amount of GitHub Sponsors received in 2023 is as follows:

Year	Total Amount (USD)
2023	$14,600

The monthly amount of GitHub Sponsors received in 2023 is as follows:

Date	Amount (USD)
2023/01	$1,200
2023/02	$1,200
2023/03	$1,200
2023/04	$1,200
2023/05	$1,200
2023/06	$1,200
2023/07	$1,200
2023/08	$1,200
2023/09	$1,200
2023/10	$1,200
2023/11	$1,300
2023/12	$1,300

I received about $1,200 to $1,300 per month in 2023.

📝 I live in Japan, so I actually receive it in Japanese yen.

Current ongoing sponsors

A following graph summarizes information only for ongoing sponsors (CURRENT SPONSORS) as of December 2023.
This graph does not include past sponsors (past sponsors), so basically it does not include information on One-Time sponsors.
This graph is generated by the following tool.

azu/github-sponsor-report: GitHub Sponsors report generator

The following graph shows the number of people who continue to support us with GitHub Sponsors.

Number of GitHub Sponsors by month (Past sponsors are not included)

The following graph shows the estimated revenue per month (in US$) for GitHub Sponsors.

Estimated income from GitHub Sponsors per month (in US$)

Conclusion

This article summarized the income from GitHub Sponsors in 2023.

I think it is important that there is a system that allows not only code contributions but also financial contributions.
Compared to last year, I feel that more people are using GitHub Sponsors.

For example, Sentry uses a service called thanks.dev to automatically distribute money to maintainers of libraries that depend on it.

We Just Gave $500,000 to Open Source Maintainers | Product Blog • Sentry

I think that systems like GitHub Sponsors/Open Collective will continue to be discussed and new methods will be developed.

Acknowledgements

Thanks to those who support me with GitHub Sponsors!

This List of GitHub Sponsors generated using SponsorKit

My sponsor page is following:

Sponsor @azu on GitHub Sponsors

Secretlint 6: masking API tokens in .bash_history and .zsh_history

azu — Tue, 03 Jan 2023 12:26:00 +0000

We have released Secretlint v6, which finds API tokens, passwords, and other sensitive information contained in files.

Release v6.0.1 - secretlint/secretlint

Secretlint, when executed with a glob or file, such as secretlint "**/*", finds confidential information contained in the file and prints it to standard output.
On the other hand, unlike ESLint and textlint, Secretlint cannot be automatically modified with --fix.
This is because finding and deleting API tokens, etc. will simply break them.

Therefore, any sensitive information found must be reported and manually fixed by the user.
For example, modify it so that it is not hard-coded into the source code, but rather received in an environment variable, etc.

secretlint/credentials-is-secret.md at master - secretlint/secretlint - GitHub

In most cases, you can't automatically fix any confidential information you find, but I've noticed that it's OK to automatically remove or mask any confidential information that has been left in .bash_history or .zsh_history.
To automatically modify API tokens left in history files, Secretlint v6 adds a --format=mask-result formatter .

Usage: masking confidential information in `.zsh_history`.

The secretlint package itself does not contain rules, but the @secretlint/quick-start package ships with recommended rules, so here is how to do it using @secretlint/quick-start.

Requirements: Node.js 16+

You can check if .zsh_history contains sensitive information with the following command.
(You can also check .bash_history by simply changing the file name)

npx @secretlint/quick-start ~/.zsh_history

~/.zsh_history
  9178:25 error [GITHUB_TOKEN] found GitHub Token(GitHub personal access tokens): ghp_wWPw5k4aXcaT4fNP0UcnZwJUVFk6LO0pTEST  @secretlint/secretlint-rule-preset-recommend > @secretlint/secretlint-rule-github

✖ 1 problem (1 error, 0 warnings)

If included, an error will be reported.
Before masking this sensitive information, back up .zsh_history just in case.

cp ~/.zsh_history ~/.zsh_history.bak

You can use --format=mask-result to see the results of masking sensitive information in ~/.zsh_history on standard output.

npx @secretlint/quick-start ~/.zsh_history --format=mask-result

...
: 1672748457:0;GITHUB_TOKEN="****************************************" gh issue list
...

If all is well, use the --output option to overwrite ~/.zsh_history with the masked results.
(Do not overwrite with <command> > ~/.zsh_history)

npx @secretlint/quick-start ~/.zsh_history --format=mask-result --output ~/.zsh_history

Finally, delete the ~/.zsh_history.bak that you backed up.

rm ~/.zsh_history.bak

Motivation

Last month, there was a supply chain attack against PyTorch's PyTorch-nightly using Dependency Confusion.

Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022. PyTorch

pip installs PyPI first (strictly speaking, index-url is preferred over extra-index-url) if the in-house repository (registry) and PyPI have the same package name.
Therefore, if you upload malicious code to PyPI with the same name as a package that PyTorch-nightly depends on but was not yet in PyPI, the malware will be automatically installed when you install PyTorch-nightly.
This problem is called Dependency Confusion.

The same problem exists with npm, etc.

Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies | by Alex Birsan Medium

When a private registry such as JFrog Artifactory is used in conjunction with a public registry, it is easy to have the same name but different contents in different registries. The following article summarizes how to deal with this Dependency Confusion, and talks about combining measures such as not mixing registries, using namespaces for package names, and using lock files.

3 Ways to Mitigate Risk When Using Private Package Feeds

The PyTorch-nightly malware seems to have included a process that uploads and steals files in $HOME/* in addition to environment variables, system information, /etc/hosts, /etc/passwd and .ssh/.

The .ssh/ directory can be managed with an SSH key, such as 1Password, so that it cannot be stolen with only the permission to read files.

1Password for SSH & Git | 1Password Developer Documentation

Credentials are often stored as raw text in .config/ or ~/.aws.
These can be found in 1Password Shell Plugins, op run, zenv, envchain, etc. to avoid storing raw tokens in files.

Other things that can easily be credentialed in the HOME directory are shell history files such as .zsh_history and .bash_history.
I was not comfortable deleting all the history files, and on the other hand, it is troublesome to check them visually, so I thought it would be a good idea to use secretlint to check them automatically.

Although Secretlint does not have an automatic correction mechanism like --fix, I thought it would be possible to implement a pseudo automatic correction by devising an implementation of a formatter that displays error results I implemented a --format=mask-result formatter.

I actually found some issues of them when I tried it, so I masked them out and removed them from the history.

My GitHub Sponsors Revenue @ 2022

azu — Sat, 31 Dec 2022 14:03:16 +0000

This is a summary of GitHub Sponsors revenue earned in 2022.
GitHub Sponsors is primarily a mechanism to provide financial support for open source activities.

GitHub Sponsors can be individuals or organizations, and this section summarizes GitHub Sponsors for myself personally.
The GitHub Sponsors for myself (@azu) are listed on the following page.

Types of open source activities

The following are the types of open source activities that I am involved in.

Software development: textlint, Secretlint, HonKit and other development and maintenance.
Web service development: philan.net, Komesan, Irodr, etc.
Blogs: Posting on JSer.info and ECMAScript Daily blogs
Books: Writing for JavaScript Primer and JavaScript Promise book

None of these are related to my job, but are hobbies.

Because it is a hobby, I have almost no set quid pro quo for sponsors (I try to avoid any form of support for specific projects).
More details about the tier design of my GitHub Sponsors can be found in the following article.

Looking Back on Two Years of GitHub Sponsors - DEV Community 👩‍💻👨‍💻

Types of income

Most of my open source-related income is via GitHub Sponsors.
The @azu's GitHub Sponsors page offers both Monthly and One-Time support.
In my case, my support is based on Monthly support from GitHub Sponsors.

Amount of income

When you support us through GitHub Sponsors, you will be paid in US dollars, which will be converted to Japanese yen at the time of transfer.
Therefore, the actual amount received will be in Japanese Yen.

There are also two types of support options for GitHub Sponsors: Monthly and One-time.
The amounts listed here include both amounts.
The total amount of GitHub Sponsors received in 2022 is as follows

Year	Total Amount (US $)
2022	$12,799

The monthly amounts of GitHub Sponsors received in 2022 are as follows

Date	Amount (US $)
2022/01	$944.40
2022/02	$860.18
2022/03	$564.15
2022/04	$1,197.38
2022/05	$1,194.30
2022/06	$1,021.21
2022/07	$1,631.31
2022/08	$772.74
2022/09	$1,335.83
2022/10	$1,140.43
2022/11	$1,107.06
2022/12	$1,030.18

The reason why there is a wide range in the monthly amount is because the timing of the payment for those who support the project is divided into daily payments, so there seems to be a blurring of the amount in the timing of the transfer.
In addition, the months with One-Time support are added to the Monthly support.
The reason for the large increase only in July 2022 is that GitHub Maintainer Month received about $500 in One-Time support from GitHub, Inc.

Current ongoing sponsors

Since there is a blurring range when looking at the actual transfer timing amounts, to smooth it out, this graph summarizes information only for ongoing sponsors (CURRENT SPONSORS) as of December 2022.
This graph does not include past sponsors (past sponsors), so basically it does not include information on One-Time sponsors.
This graph is generated by the following tool.

azu/github-sponsor-report: GitHub Sponsors report generator

The following graph shows the number of people who continue to support us with GitHub Sponsors.

Number of GitHub Sponsors by month (Past sponsors are not included)

The following graph shows the estimated revenue per month (in US$) for GitHub Sponsors.

Estimated income from GitHub Sponsors per month (in US$)

Starting around April 2022, estimated income at GitHub Sponsors has averaged over $1,000.

Conclusion.

This is a summary of the income that will be earned by GitHub Sponsors in 2022.

The reason for publishing this article is to get people, both those who are active in open source and those who support open source, interested in financial support mechanisms such as GitHub Sponsors.

In my opinion, it is important to be able to choose financial support as a method of support.
Therefore, I see GitHub Sponsors and others as a type of open source support method.

There are now mechanisms such as GitHub Sponsors and Open Collective that allow individuals and organizations to support open source financially as well. Both supporters and recipients should consider taking advantage of these programs.

For more information on how to support using GitHub Sponsors, please see the following article.

How to support open source with GitHub Sponsors, even if you're new to it

For more information on setting up your profile and tier when accepting GitHub Sponsors, please see the following article.

Acknowledgements

Thanks to those who support us with GitHub Sponsors.

List of GitHub Sponsors generated using SponsorKit

Looking Back on Two Years of GitHub Sponsors

azu — Thu, 28 Oct 2021 12:54:12 +0000

This article is a look back on GitHub Sponsors as it has been almost two years since I started recruiting GitHub Sponsors.

In this article, I write about the reason why I started GitHub Sponsors, the design of the tier, the result and gratitude of doing it, changes by doing it, and advice for those who will do it in the future.

// Detect dark theme var iframe = document.getElementById('tweet-1186972124180701184-698'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1186972124180701184&theme=dark" }

My Tweet notifying you that I've started GitHub Sponsors

Why Starts GitHub Sponsors

There are several reasons why I started GitHub Sponsors.

I wanted to try using GitHub Sponsors.
- GitHub is the web service I use the most, so I wanted to use the new features.
I wanted to have a way to financially contribute to open source.
- As was the case with the Promise book, the lack of a way to pay for open source is also a problem, so I wanted a place to solve this problem.
No fees.
- Since we're basically looking to continue, it's important that there's no cost to continue
- About GitHub Sponsors for open source contributors - GitHub Docs

GitHub is the service I use the most, so I wanted to try out GitHub Sponsors as a new feature.

The other major reason is that I believe that open source users should have a way to pay for open source.
It is important that users of open source have the option to sponsor (financially support) the open source as a way to contribute to it.

There are many ways to contribute to open source, such as bug reporting/fixing, adding features, writing documentation, triage of issues and discussions, design, marketing, etc.
One of the ways to contribute is through financial support.
As one of the ways to get involved, I think it would be desirable for Contributors to be able to choose the option of providing financial support.

The idea itself came about when I released the JavaScript Promise book as an open-source book, and readers found the bug that there was no way to pay for the book, I thought of this when I fixed it.

I use GitHub Sponsors because I often release products for myself (developers) as open source, and GitHub Sponsors was just the right way to create an option for support.

Designing Tiers for GitHub Sponsors

GitHub Sponsors offers monthly and one-time payment options.
You can set up to 10 different tiers (10 different amounts) for each of the monthly and one-time payment methods.
In the beginning, only monthly payment will be available.
In April 2021, Custom Amounts and one-time payments has beed added, allowing sponsors to point to any amount.

Finally, Tier of my Sponsors is set as follows.
The tier type itself has not changed much since I first created it.

✨ Supporter $1 a month
☕️ Coffee Supporter $5 a month
🌐 Domain Supporter $10 a month
📖 Book Supporter $30 a month
💚 JSer.info Sponsor $100 a month
❤️ Open Source Sponsor $300 a month

📝 JSer.info is my website in japanese. This blog is similar with JavaScript Weekly.

The actual page can be seen at the following link.

Sponsor @azu on GitHub Sponsors

I believe that people who are willing to be GitHub Sponsors are willing to continue to support me because they want me to continue our activities.
I think it's brave and amazing to continue to support them.

In order to continue working on this support, I set my tier design to have as few immediate benefits as possible.

There are two main reasons for this.

For the purpose of long-term activities: I envision continuous support and continuous activities.
To avoid being tied to a specific project: certain benefits tend to be directly linked to a specific project.

While the immediate benefits (priority support for Issues, chat support, etc.) have the advantage of being easy to encourage action, it is difficult to consider what will happen in the long term.

Since the motivation of both parties (the sponsors and the sponsored) is affected by the benefits, I believe that it is difficult to intuitively grasp what will happen in the long run.

On the other hand, if there is no visible benefit, it is a little more intuitive for the sponsored party to continue some kind of activity (in this case, open source activity) as an answer to the sponsored party.

The ability to continue open source activities depends on people's money/time/health/motivation.
However, donations give positive feedback on health, and the fact that there are several studies that show that the money from the support can be used to save time, I am optimistic about this area.

In my case, the other reason "To avoid being tied to a specific project" is also related to motivation.
I believe that the benefits of being tied to a specific project make it easier to create a sense of responsibility for the maintenance of that project.

Creating such benefits seemed to have a tendency to become a burden for me, so I tried not to incorporate benefits that are tied to a specific project as a Tier.

Only "💚 JSer.info Sponsor" is somewhat special, because JSer.info was intended to minimize costs from the beginning, JSer.info has been around for more than 10 years, JSer.info Policy, and so on.
I thought that my awareness wouldn't change much with or without GitHub Sponsors, so I put them in a separate box.

I think this is the part where people are free to decide what kind of Tier they want and have different ideas about it.
Therefore, this is not the right answer, but I wrote about my Tier design again.

📝 If I were to design the tiers now, I think it would be easier to reduce the number of tiers because of the Custom Amount (users can freely decide the amount).
However, since there was no Custom Amount at first, and the Amount cannot be changed later, the Tier design is as it is now.

In addition, the current Sponsor Dashboard shows the following tier ideas.
If you are planning to set up a tier, you may want to refer to this as well.

The results of recruiting GitHub Sponsors

At the moment (2021-10-28), I have about 100+ people supporting me with GitHub Sponsors. (Thank you very much!)
Estimated monthly income of GitHub Sponsors is $1000+.

The specific number of sponsors and Monthly Estimated Income ($) have been changing in the following way.

Number of sponsors per month on GitHub Sponsors

Estimated monthly income from GitHub Sponsors in US dollars.

About 20 people have continued to support GitHub Sponsors since the beginning of the project, and the number has been increasing at a steady pace since then.

Basically, it's been a steady pace, but I think the increase in March 2021 and June to July 2021 is due to people mentioning GitHub Sponsors in their releases.

寄付をするために、寄付の予算と寄付の記録をSpreadSheetベースでつける philan.net というサービスを作った | Web Scratch (Japanese Blog)
ES2021に対応したJavaScript Primer 3.0を公開しました - JavaScript入門 | Web Scratch (my new JavaScript Book announcement)

The reason for the large change in Monthly Estimated Income between December 2020 and June 2021 is that Cybozu and VELC have sponsored me.
They have each written articles about their GitHub Sponsors as companies.

Edit: After publishing the Japanese version of this article, the number of sponsors increased.

📝 The report image used here is created with a tool called github-sponsor-report. This report does not include data from people who quit in the middle of the report, so the actual number should be higher or lower. So, please take a look at it for the atmosphere.

The github-sponsor-report is open source, so if you want to make your own GitHub Sponsors dashboard, please use it! You can use it to create your own GitHub Sponsors dashboard.

Benefits of being supported by GitHub Sponsors

First of all, thanks to all the GitHub Sponsors out there!

One thing that has changed since I started as a GitHub Sponsor is that the financial/psychological burden of ongoing maintenance costs has eased.

I've always been very cautious about increasing maintenance costs.
I have always been cautious about increasing maintenance costs, especially for domains and subscriptions, but I think GitHub Sponsors has reduced this burden considerably.

Specifically, I had a policy of not getting a domain name unless there was something wrong with it, but thanks to the existence of 🌐 Domain Supporter, I was able to get a domain name without hesitation when I created philan.net.
(Now I am trying to move the backend of philan.net from Vercel to AWS, so it was a good decision to get a domain name.

Also, I'm an ACM member to read Oreilly's books by subscription, and I can pay $99/year without hesitation, thanks to the existence of 📖 Book Supporter.

With the financial burden offset, I felt that the psychological burden of development and learning was reduced.

New things I've started after recruiting GitHub Sponsors

GitHub Sponsors has not only reduced my workload, but has also given me more opportunities to work on new things.

philan.net is a perfect example of this.
I was thinking about GitHub Sponsors itself, and was researching the history and structure of donations.

The philan.net project I started was to create a system to manage donations and put it into practice, because the best way to learn more about how donations work is to try to donate.

I looked at the ratio of the amount of commits to repositories created before I started GitHub Sponsors (2019) to the amount of commits to repositories created after I started (2020).
The repositories I am dealing with here are Public repositories only, so Private repositories are not included.

The following figure shows the number of commits made to each repository in each year of 2019 and 2020.

Spreadsheet: https://docs.google.com/spreadsheets/d/1OZz4GvORzt2YORbiJPX_QzjggoviJAV2vNDJeubQfE4/edit?usp=sharing

Source Code: https://github.com/azu/github-commit-count-per-repository

The number of repositories committed in each period was as follows. (Only Public repositories are included).

The total number of repositories with commits in the two time periods of 2019 and 2020 is 322.
Of those, 92 repositories had continuous commits in either of the two periods.
The total number of repositories with commits in one or the other period is 230.
- This includes temporary repositories (e.g. testing) and new repositories.
The total number of commits in 2019 is 8073.
The total number of commits in 2020 is 10656

Continuously committed repositories include JSer.info, textlint, and JavaScript Primer, etc.
On the other hand, the newly created ones after the launch of GitHub Sponsors include philan.net, HonKit, Secretlint, etc.

This is not very accurate because it includes commits by bots such as dependabot, but I think the amount of commits to new ones is still increasing.
It seems that some percentage of them are still committing.

I've written a lot of things, but to summarize, the number of commits has increased even after starting GitHub Sponsors, and the number of repositories I've published has also increased.

I've been able to challenge myself to create new things, and the ones that have some kind of demand are still being maintained.

For those thinking about GitHub Sponsors.

For Developer

There are some people who do not want to receive money for their open source activities.

I know there are reasons for this, such as not wanting to feel obligated or responsible for receiving money.
However, if you try to design your own tier, you may find that it reduces the burden on your feelings, so please consider it.

Of course, this does not mean that everyone should be a GitHub Sponsor, so please reconsider when the need arises.

Getting Paid for Open Source Work | Open Source Guides

Also, I recommend that you don't feel too guilty about asking people to support you.

The people who are actually using your library or referring to what you have written must feel the value in it.
Asking for support from those who feel value is a healthy way to maintain the activity.
Conversely, those who feel valued may be looking for ways to help.

Jeff Geerling said same things:

For other maintainers: Don't feel guilty asking people to support you. Whether they'll admit it or not, if they're using your project, they are getting value out of it. And in the case of organizations building on top of your projects, usually a lot. Don't get all spammy (there's a reason we distrust salespeople...), but definitely ask people to assist you financially.
I'm thankful for GitHub, Patreon, and my sponsors this year | Jeff Geerling

Finally, it's only recently that people have been able to provide easy financial support for open source, so there's a lot to be said for not actually doing it.

For Sponsors

It's great to be a sponsor of someone.

It doesn't matter how big or small the amount of money you are supporting, it means a lot.
In particular, I felt that the montly support is more meaningful than the amount of money (at least that's how I felt for myself).

I also started writing this article to explain how I feel about being supported to those who support me.
Since my tier does not have a clear set of returns, I am writing articles like this one and the year-end report, but I am grateful for their support.

For Company

GitHub Sponsors and Open Collective allow companies to support specific people and open source projects.

If you are an employee and need to explain to your company why you are sponsoring an open source project, the following article describes various approaches to support.

How to talk to your company about sponsoring an open source project - Human Who Codes
- An article on how to talk to your company about sponsoring an open source project, written by the author of ESLint.

It is said that over 90% of companies use some kind of open source software/library.
If you don't know what to support, talk to people who use open source, such as software engineers.

If you are using some form of open source as a company and are interested in open source as a part of the software supply chain, the following reports and documents are recommended.

It describes the problems and risks of the lack of open source maintainers. In other words, you may be able to find out what you can do to support the safe use of open source.

If you want to know more about the economic impact of open source on a larger scale, I recommend the EU report on open source for more details.

Study about the impact of open source software and hardware on technological independence, competitiveness and innovation in the EU economy | Shaping Europe’s digital future

Conclusion

It's been about two years since I started recruiting GitHub Sponsors in October 2019, so I thought I'd take another look at GitHub Sponsors.

I wrote about why I started recruiting GitHub Sponsors, what I thought about it, and how it turned out.
One of the purposes of this article is to explain the impact and value of the program to those who support me.

Japanese Version: GitHub Sponsorsの募集を始めてから2年が経ったので振り返る | Web Scratch

You can register your own GitHub Sponsors on the following page. If you'd like to help, that would be great!

Sponsor @azu on GitHub Sponsors

🛡🔑 Secretlint 4.0.0: Support ESM rule and secretlint-disable directive

azu — Wed, 15 Sep 2021 12:23:05 +0000

secretlint is pluggable linting tool to prevent committing credential like SSH private key, GCP Access token, AWS Access Token, Slack Token, and npm auth token.

It is similar one of ESLint, but it is for security.

New Features 🆕

ESM rule support #187

Secretlint allow to load secretlint rule as ESM(ECMAScript modules).
You can write secretlint rule as ESM.

For more details, pleases see document.

https://github.com/secretlint/secretlint/blob/master/docs/secretlint-rule.md

📝 Currently TypeSript + Node.js ESM is hard to work.
Secretlint use some workaround for this. For more details, see next issue.

Use native dynamic import() · Issue #197 · secretlint/secretlint

Support `secretlint-disable` directive #195

@secretlint/secretlint-rule-filter-comments support disable comment like secretlint-disable.

This rule is included in @secretlint/secretlint-rule-preset-recommend.

// secretlint-disable -- disable all rules

THIS IS SECRET A
THIS IS SECRET B
THIS IS SECRET C

// secretlint-enable -- enable again

// secretlint-disable-next-line @secretlint/secretlint-rule-secret-alphabet -- disable specific rule in next line
THIS IS SECRET D
THIS IS SECRET E // secretlint-disable-line -- disable current line

If you want to use this directive in shellscript, you can use # secretlint-disable.

# secretlint-disable-next-line
echo "THIS IS SECRET, BUT IT WILL BE IGNORED"

For more details, see https://github.com/secretlint/secretlint/blob/master/docs/configuration.md

Breaking Changes

use `export const creator` instead of `export default` #190

Secretlint rule should use named export insteadof default export.
It is caused is thatDynamic Import in CommonJS is broken https://github.com/secretlint/secretlint/issues/190

If you have a secretlint rule, please change following.

- export default creator;
+ export { creator }

Require Node.js 12 and update `engines` #193

Now, Secretlint requires Node.js 12+
It aims to support ECMAScript modules.

Secretlint it-self is not Pure ESM package, but we will make it ESM.

Reaction will help us ❤️

How to set GitHub Actions's `permissions`?

azu — Wed, 21 Jul 2021 00:45:45 +0000

GitHub introduce permissions fields on GitHub Actions for security reasons.

The permissions field will help you to prevent software supply chain attack.

For example, codecov's bash script is hacked recently.

Bash Uploader Security Update - Codecov

This supply chain attack affects to CI like Circle CI, GitHub Actions.

GitHub Actions can limit each actions's permissions.

For example, next permissios only allow the action to read repo's content.

permissions:
    contents: read

The default permissions is write-all.
Of course, you can change the default workflow permission of the repository.

So, you need to do following to improve security of GitHub Actions.

Change the default permissiont to "Read repository contents permission "
Write each actions's permissions to yaml files

However, permissions is optional and it is a little of hard to set. Because, almost actions does not provides permissions guide.

@pkgdeps/update-github-actions-permissions

I've created a tool that update GitHub Actions's permissions automatically.

This tools detect using Actions and add permissions field to your action yaml file.

Requirements: Node.js 14+

You can update your GitHub Actions via following command:

npx @pkgdeps/update-github-actions-permissions ".github/workflows/*.{yaml,yml}"

This tool supports 40+ actions.

If you found missing actions, please submit a pull request.

pkgdeps/update-github-actions-permissions: A CLI that update GitHub Actions's permissions automatically

secretlint v3.0 support GitHub’s new authentication token detection - DEV Community 👩‍💻👨‍💻

secretlint can mask the secrets

azu — Mon, 12 Jul 2021 13:49:44 +0000

secretlint is a pluggable linting tool to prevent committing credential.

secretlint 3.3.0 support --maskSecrets option that mask the actual secret of outputs.

Release v3.3.0 · secretlint/secretlint

For example, secretlint found AWS Secret Access key and report it. With --maskSecrets, secretlint mask the secrets in outputs.

$ secretlint --maskSecrets .credential

/Users/user/.credential
  1:0  error  [AWSSecretAccessKey] found AWS Secret Access Key: ****************************************  @secretlint/secretlint-rule-preset-recommend > @secretlint/secretlint-rule-aws

✖ 1 problem (1 error, 0 warnings)

It will help you to integrate secretlint with CI like GitLab.

https://docs.gitlab.com/ee/user/application_security/secret_detection/

For more details, see original issue.

Option or formatter to not echo the actual secret to stdout · Issue #176 · secretlint/secretlint

secretlint v3.0 support GitHub’s new authentication token detection

azu — Sat, 29 May 2021 07:30:31 +0000

secretlint is a pluggable linting tool to prevent committing credential.

secretlint/secretlint: Pluggable linting tool to prevent committing credential.

secretlint is similar tools to git-secrets, but it is more flexible and support more credentials.

secretlint v3.0 support new GitHub Token format.

Release v3.0.0 · secretlint/secretlint

Recently, GitHub introduce new authentication token format.

The character set changed from [a-f0-9] to [A-Za-z0-9_]
The format now includes a prefix for each token type:
ghp_ for Personal Access Tokens
gho_ for OAuth Access tokens
ghu_ for GitHub App user-to-server tokens
ghs_ for GitHub App server-to-server tokens
ghr_ for GitHub App refresh tokens

secretlint support them!

azu

@azu_re

secretlint 3.0.0 released🎉
You can prevent to commit GitHub Tokens!

github.com/secretlint/sec…

03:16 AM - 29 May 2021

Usage

You can use secretlint as Docker Container or Node.js CLI.

If you already have installed Docker:

docker run -v `pwd`:`pwd` -w `pwd` --rm -it secretlint/secretlint secretlint "**/*"

If you already have installed Node.js:

npx @secretlint/quick-start "**/*"

secretlint also support custom rules like ESLint.
If you want to configure it, please see secretlint documenataion.

You can setup pre-commit Hook per project or pre-commit Hook globally.
This git's pre-commit prevent you to commit your credentials like GitHub Token, SSH key, AWS crendentials.

If you want to know about secretlint, please visit secretlint/secretlint.

Git Hooks without extra dependencies like Husky in Node.js project

azu — Mon, 22 Feb 2021 02:47:41 +0000

Git 2.9+ supports core.hooksPath for local git hooks, so we do not need extra dependencies like husky.

lint-staged recommented to use with husky.
However, husky v5.0.0 is licesed under The Parity Public License.

When will version 5 be MIT license again? · Issue #857 · typicode/husky

We can use core.hooksPath instead of husky.

📝 husky v5 also use core.hooksPath internally. It is a wrapper for some commands and provide extra features.

Setup

Setup for lint-staged.

1. mkdir .githooks
2. Create .githooks/pre-commit and put the following content.

.githooks/pre-commmit:

#!/bin/sh
npx --no-install lint-staged

3. Add prepare lifecycle script to package.json

  "scripts": {
    "prepare": "git config --local core.hooksPath .githooks"
  },

Complete to setup! 🎉

This prepare hooks is exected when the user has run npm install or yarn install.

📝 You can also use postinstall hook.
However, If your package is not private and you're publishing it on a registry like npmjs.com, you should not use postinstall scripts.

Pros

no dependencies

Cons

not available add command like husky add
can not run local hooks and global hooks at once(husky <=v4 and simple-git-hooks allow it because these does not use core.hooksPath)

Example

It is an example repository.

azu/githook-lint-staged-example: Git 2.9+(core.hooksPath) + Lint Staged without extra dependencies.

Note

Some environment like Cloudflare Pages or Heroku clone the repository without .git directory for deploying the repository.

In the env, you will see the following errors

fatal: Not a git repository

You can avoid this error by following changes.

  "scripts": {
-    "prepare": "git config --local core.hooksPath .githook"
+    "prepare": "git config --local core.hooksPath .githook || echo 'Can not set git hooks'"
  },

Use GitHub Issues for Personal Task Manager

azu — Sat, 09 Jan 2021 01:30:37 +0000

Recently, I have used GitHub issues for personal task manager.
Previously, I used Producteev, TickTick, OmniFocus as task manager.
But, the existing task manager has two problems.

Problems

Duplicated of GitHub Issues
- GitHub Issues already has tasks as an issue
- I do not want to create duplicated tasks on existing task manager
Hard to extend task manager by programming

So, I've created missue template repository to resolve this problems.

missue

It helps us to use GitHub as a personal task manager.

azu/missue: A Toolkit helps you to management your TODO based on GitHub Issues.

missue is just a template repository, so you can just Use this template.

missue can sync CR issue's state.
"CR" is Cross-Reference Issues.
You can create Cross-Reference Issues with userscript from other repositories.

Cross Reference Issues has a link that you want to track and has CR label.

Example: https://github.com/azu/missue/issues/4

missue is almost plain GitHub issues.
However, GitHub issues have enough features for me.

Issues
Label
Milestone
Project boards
Automation(GitHub Actions)

Additionally, you can extend GitHub issues by GitHub Actions and Probot.

For example, if you want to get a reminder feature, and you can use Probot: Reminders.
Also, GitHub Actions help you to extend your workflow by programming.

After all, GitHub issues was necessary and sufficient for me.

Generate GitHub Actions Badge from Command Line

azu — Sun, 21 Jun 2020 03:37:57 +0000

I've created github-actions-badge.
It generate GitHub Actions badge Markdown cod from command line.

[![Actions Status: test](https://github.com/azu/github-actions-badge/workflows/test/badge.svg)](https://github.com/azu/github-actions-badge/actions?query=workflow%3A"test")

This badge spec is here.

https://help.github.com/en/actions/automating-your-workflow-with-github-actions/configuring-a-workflow#adding-a-workflow-status-badge-to-your-repository

Install

Install with npm:

npm install github-actions-badge --global

Usage

Usage
  $ github-actions-badge

Options
  --format "markdown", "json"

Examples
  # Copy GitHub Action as Markdown format
  $ github-actions-badge | pbcopy

Example

$ github-actions-badge
[![Actions Status: test](https://github.com/azu/github-actions-badge/workflows/ci/badge.svg)](https://github.com/azu/github-actions-badge/actions?query=workflow%3Aci)

Source

azu/github-actions-badge: Generate GitHub Actions badge Markdown code.

Forem: azu

JSer.info 15th Anniversary: Looking Back at 15 Years of JavaScript

What is JSer.info?

Basic Statistics Over 15 Years

Changes in Information Sources: From Personal Blogs to Official Documentation

Early Period (2011-2013) Main Sources

Middle Period (2017-2019) Main Sources

Late Period (2023-2025) Main Sources

Changes in Content Types

Evolution of Japanese Blog Platforms

Technology Trend Changes

UI Frameworks: jQuery → Angular → React

Build Tools: webpack → Vite

Runtimes: From Node.js Dominance to Diversification

Technologies with Changed Mentions on JSer.info

Technologies That Disappeared (2011-2013 → 2023-2025)

Technologies with Increased Mentions

Changes in Cross-Cutting Topics

Changes in Information Source Types

Changes in Development Practices

Summary of 15 Years of Change

Changes to JSer.info Itself

Technical Changes

Operational Changes

Progress on the "Make It Replaceable" Goal

About 2025 Update Frequency

Conclusion

JSer.info Sponsors

Related Links

My GitHub Sponsors Revenue @ 2023

Types of open source activities

Amount of income

Current ongoing sponsors

Conclusion

Acknowledgements

Secretlint 6: masking API tokens in .bash_history and .zsh_history

Usage: masking confidential information in .zsh_history.

Motivation

My GitHub Sponsors Revenue @ 2022

Types of open source activities

Types of income

Amount of income

Current ongoing sponsors

Conclusion.

Acknowledgements

Looking Back on Two Years of GitHub Sponsors

Why Starts GitHub Sponsors

Designing Tiers for GitHub Sponsors

The results of recruiting GitHub Sponsors

Benefits of being supported by GitHub Sponsors

New things I've started after recruiting GitHub Sponsors

For those thinking about GitHub Sponsors.

For Developer

For Sponsors

For Company

Conclusion

🛡🔑 Secretlint 4.0.0: Support ESM rule and secretlint-disable directive

New Features 🆕

ESM rule support #187

Support secretlint-disable directive #195

Breaking Changes

use export const creator instead of export default #190

Require Node.js 12 and update engines #193

How to set GitHub Actions's `permissions`?

@pkgdeps/update-github-actions-permissions

Related

secretlint can mask the secrets

secretlint v3.0 support GitHub’s new authentication token detection

Usage

Git Hooks without extra dependencies like Husky in Node.js project

Setup

Pros

Cons

Example

Note

Use GitHub Issues for Personal Task Manager

missue

Generate GitHub Actions Badge from Command Line

Install

Usage

Usage: masking confidential information in `.zsh_history`.

Support `secretlint-disable` directive #195

use `export const creator` instead of `export default` #190

Require Node.js 12 and update `engines` #193