Upstream a Stable Library API for the Action

[rickstaa]

We should upstream a small, stable library API in github-readme-stats so the Action can depend on it instead of internal handler wiring. This would simplify the Action, reduce breakage from internal refactors, and make releases more reliable.

Proposed scope:

• Extract card-rendering logic into a supported API (e.g., package exports)
• Publish and consume a semvered library so the Action can pin versions
• Update the Action to use the new API and remove handler maps once available

[marcalexiei]

Hello,
I’m interested in helping with the creation of an upstream library.

---

Extract card-rendering logic into a supported API (e.g., package exports)

Do you intend to expose all available render methods via explicit exports?

For example:

import { renderStatsCard, renderPinCard } from 'github-readme-stats/cards';

---

Publish and consume a semvered library so the Action can pin versions

It would also be beneficial to publish TypeScript declaration files alongside the runtime code to improve the developer experience.

Currently, the source uses the @ts-check directive, which suggests the codebase is already compatible with static typing. Adding a build step to generate .d.ts files should therefore be straightforward.

---

As initial step, I propose generating a dist folder for the api directory using a minimal tsc configuration.

Please let me know if you would like me to open a PR implementing this proposal.

[rickstaa]

Hello, I’m interested in helping with the creation of an upstream library.

Extract card-rendering logic into a supported API (e.g., package exports)

Do you intend to expose all available render methods via explicit exports?

For example:

import { renderStatsCard, renderPinCard } from 'github-readme-stats/cards';

Publish and consume a semvered library so the Action can pin versions

It would also be beneficial to publish TypeScript declaration files alongside the runtime code to improve the developer experience.

Currently, the source uses the @ts-check directive, which suggests the codebase is already compatible with static typing. Adding a build step to generate .d.ts files should therefore be straightforward.

As initial step, I propose generating a dist folder for the api directory using a minimal tsc configuration.

Please let me know if you would like me to open a PR implementing this proposal.

Hey @marcalexiei, it’s great that you want to help get this library maintained again. 🚀 I’m currently out of the office, so I can’t give a detailed response right now. In the meantime, as mentioned in anuraghazra/github-readme-stats#3851 (comment), @martin-mfg and I have joined forces to get the project maintained again. He can add you to the maintainers group.

[marcalexiei]

Thanks for your feedback @rickstaa!

@martin-mfg I would be happy to join the maintainers group!

If you agree, I can start opening issues with my proposals on https://github.com/stats-organization/github-stats-extended.
This appears to be the appropriate repository for suggesting changes, including those related to the npm package API.

[martin-mfg]

Hi @marcalexiei, I have invited you to https://github.com/stats-organization . Yes, please add your suggestions in https://github.com/stats-organization/github-stats-extended . If you want you can also contact me on discord: martin_mfg.