Forem: Patryk Zdunowski

What do you think about the open source condition in 2025?

Patryk Zdunowski — Thu, 28 Aug 2025 11:52:25 +0000

Hi all,

I want to conduct deeper research about the condition of open source projects in the past years to confirm/refute my hypothesis.

While statistical analysis is very useful, I would like to ask developers/community first what you think about open source right now (for the year 2025). Things like project sustainability, licensing trends, or how the big projects are evolving?

This is open to discuss - without any angle.

⭐ Every Star Matters ⭐ - Celebrating Our 25th!

Patryk Zdunowski — Wed, 27 Aug 2025 12:46:39 +0000

Just hit 25 stars on xyd - our open source docs framework! 🚀

Thanks to everyone who starred it! What started as solving our own problem has turned into something others find useful too.

What about you?

🌟 What's your current star count?
💡 What project are you working on?

How to deploy React Router Server Components on Netlify

Patryk Zdunowski — Mon, 25 Aug 2025 15:53:08 +0000

Recently, React Router introduced experimental support for Server Components, and I'm excited about how this will revolutionize how we build React applications with server-side rendering capabilities.

I've been exploring this feature because it brings the power of server-side rendering directly into React Router, eliminating the need for complex SSR setups. The ability to fetch data and render components on the server while maintaining React's familiar patterns is a game-changer.

However, it's actually quite straightforward to deploy on Netlify right now:

The key is configuring your netlify.toml properly:

[build]
  command = "npm run build"
  publish = "dist/client"
  functions = "dist/rsc"

[[redirects]]
  from = "/*"
  to = "/.netlify/functions/index"
  status = 200

... and that's it!

You get server-side rendering, data fetching, and all the benefits of React Router's new architecture deployed seamlessly on Netlify's edge network.

Complete repository with setup instructions: https://github.com/zdunecki/how-to-deploy-react-router-server-components-on-netlify

Live demo: https://react-router-server-components.netlify.app

I can't wait for the stable release!

React Router Server Components + Syntax-Highlighting is working

Patryk Zdunowski — Sat, 23 Aug 2025 00:19:03 +0000

Recently, React Router introduced experimental support for Server Side Components, and I'm excited about how this will simplify syntax highlighting in my Docs Framework project.

I've been looking forward to this feature because xyd's codebase! is still using the old approach. Soon, syntax highlighting will be much easier and cleaner.

However, it's actually quite simple to implement right now:

import { highlight, Pre } from "codehike/code"

export async function CodeSnippet() {
  const codeblock = `
export async function HomePage() {
  const data = await fetchData()

  return (
    <div>
      <h1>{data.title}</h1>
      <p>{data.description}</p>
    </div>
  )
}
`
  const highlighted = await highlight({
    value: codeblock,
    lang: "tsx",
    meta: "Server Component",
  }, "github-dark")

  return <Pre code={highlighted} />
}

... and that's it!

Complete repository with setup instructions: https://github.com/zdunecki/react-router-server-side-components-syntax-highlighting

I can't wait for the official version!

How I manage my Google Chrome tabs and you should too

Patryk Zdunowski — Thu, 21 Aug 2025 12:16:49 +0000

Intro

Since the Google Chrome update of tab groups, I always use them. I use the whole default available palette, which draws like this:

\colorbox{#e2e3e5}{\color{#e2e3e5}{X}} \colorbox{#fff}{\color{#000000}{tools}} \colorbox{#3871e0}{\color{#3871e0}{X}} \colorbox{#fff}{\color{#000000}{infra}} \colorbox{#c84031}{\color{#c84031}{X}} \colorbox{#fff}{\color{#000000}{watch}} \colorbox{#eeae3c}{\color{#eeae3c}{X}} \colorbox{#fff}{\color{#000000}{branch}} \colorbox{#3c7e40}{\color{#3c7e40}{X}} \colorbox{#fff}{\color{#000000}{suite}} \colorbox{#bf3082}{\color{#bf3082}{X}} \colorbox{#fff}{\color{#000000}{meetings}} \colorbox{#9648eb}{\color{#9648eb}{X}} \colorbox{#fff}{\color{#000000}{etc}} \colorbox{#357981}{\color{#357981}{X}} \colorbox{#fff}{\color{#000000}{incubator}} \colorbox{#EC9550}{\color{#EC9550}{X}} \colorbox{#fff}{\color{#000000}{branch}}

I organize my tabs based on colors and a title (if necessary), which works well in my daily work routine. Let’s talk about the details.

Example final organized tabs:

Groups

\colorbox{#e2e3e5}{\color{#e2e3e5}{X}} \colorbox{#fff}{\color{#000000}{Grey (tools)}}

If you need to organize the tools you use daily, put them there. It can be, for example, GitHub.

\colorbox{#3871e0}{\color{#3871e0}{X}} \colorbox{#fff}{\color{#000000}{Blue (infra)}}

It is reserved for infrastructure, e.g Google Cloud.

\colorbox{#c84031}{\color{#c84031}{X}} \colorbox{#fff}{\color{#000000}{Red (watch)}}

This color is for watching things or recent bugs that you have to look into. To be more precise, use them, for example, for grouping things that you have to look at the corner of your eye e.g. Slack or Gmail. You can always collapse them if you need a full focus.

It’s the first use case for this group, but the second one is for grouping a list of issues that you are or might be working on. If your regular job is interrupted by reports from users, it’s a good time to keep them more organized.

\colorbox{#eeae3c}{\color{#eeae3c}{X}} \colorbox{#fff}{\color{#000000}{Yellow (feat)}}

If you are working on regular features, that’s the right place for that group. Additionally, if you are working on multiple things, you can split one feature into multiple logical groups using the name convention (described below).

\colorbox{#3c7e40}{\color{#3c7e40}{X}} \colorbox{#fff}{\color{#000000}{Green (suite)}}

Management is done in this place. It’s all things that are not strictly related to the development of a particular feature. Jira and Google Drive are the right tools to move them there.

\colorbox{#bf3082}{\color{#bf3082}{X}} \colorbox{#fff}{\color{#000000}{Pink (meets)}}

If you need organized meetings, it’s a good place, e.g “daily” meetings.

\colorbox{#9648eb}{\color{#9648eb}{X}} \colorbox{#fff}{\color{#000000}{Purple (etc)}}

Designed for internal systems that exist in your company. In my case, there are, for example, internal CMS systems.

\colorbox{#357981}{\color{#357981}{X}} \colorbox{#fff}{\color{#000000}{Teal (incubator)}}

If you do research that is not a specific work in your ticket system, you can do it right there. You’re connecting the dots here. Thanks to that, you have a separate group that is not mixed with feat. Important note - it’s not research for a particular feat, but during the work, you might have tons of ideas, and when you feel there’s a little time for that, you can group things and move them here.

\colorbox{#EC9550}{\color{#EC9550}{X}} \colorbox{#fff}{\color{#000000}{Orange (branch)}}

Reserved for a branching of a particular feat. Sometimes you might have a second hypothesis to test, so then move things there.

Order

Order is based on a few factors. Usability and density. An important thing is that density is calculated only for one group. Usability has other factors like where tabs are default created or how ‘Open Link in New Window’ works. By default, new tabs are created on the right sidebar and new link windows grow up from a group where we are.

The highest density is on the left, and on the right,it’s because new tabs and “Focus” come from the right, and the “Watch” group is on the left.

Note: Thanks to that pattern, it will be possible to create an automation using Chrome API for grouping tabs based on that formula.

Group arrangement within the order

Now, if you know what usability and density are, we can go into how you can arrange them based on the groups we mentioned before.

The “Extreme left” is reserved for occasional usage, no matter what this group is. For example, you can put tabs with groups for daily meetings meetings. These groups are always closed until you don’t need them. I recommend not putting many groups on the “Extreme left” because we need space for watch group.

After “Extreme left” is a watch. Keep them as small as possible, but have every tab you need in your daily work.

“Middle” is for every group you don’t want to use heavily at the moment. Keep them ordered as you like.

“Focus” is designed for things that you’re currently working on. This area is very close to the extreme right sidebar side where new tabs are added.

Note: In my case, it’s very often for a feat.

Name convention

Use short names and sometimes shortcuts. For example, if you have many tabs, you can use shortcuts to not expand the sidebar even more. The modifier name convention is also helpful here. It’s something that helps if your group expands quickly and you would like to create a new related one. Then I suggest using the formula <name>:<modifier>, e.g. promotion: docs.

Conclusion

I love tabs, I love tab groups even more. Google Chrome didn’t have tab groups for a long time, and none of Chrome Extensions work simply and well. Since this update, my productivity has increased a lot, and I keep my mind more orderly. Thank you, Google Chrome Team!

Please remember it’s a framework that works in my case, and I'm still looking to improve that one, but if you feel it can help you, then that’s cool!

PS: My tab list is constantly growing..

Do you like tabs too?

How I got over 13M lines of code within 182 commits in my side project

Patryk Zdunowski — Wed, 20 Aug 2025 12:11:18 +0000

🔗 My Git Activity Story Repo: https://github.com/livesession/xyd

TL;DR — Highlights ⚡

🗓️ Range: Dec 01, 2024 → Aug 19, 2025 • 262 days

🧑‍💻 Commits: 182 • Active days: 108 (41.2%)

🧾 Raw lines: ~13.8M (exact: 13,785,977) (+~7.3M (exact: 7,341,870) / -~6.4M (exact: 6,444,107))

🏆 Spike #1: May 25, 2025 — ~4.0M (exact: 3,998,050) (JSON/YAML (any) 97.9% • Tests 99.8%)

🔥 Longest streak: 108 days • ⏰ Fav hours: 23:00 (75 commits), 22:00 (14 commits), 03:00 (10 commits)

🧼 Baseline (cleaned): excludes only the exact spike-causing tests/fixtures JSON/YAML; median 3,821/day, p90 46,572/day, avg 8,955.3 lines/commit

1) Daily activity (raw) 📈

Here’s every day’s line churn (adds + deletes). One day absolutely explodes — that’s our Spike #1.

Figure 1. Daily line changes with a 7-day average. Spike #1 is highlighted.

Why I looked into this 🤔

After eyeballing the daily chart, the totals looked like millions of lines 😳.

No way that was all hand-written code — so I dug into the spikes to separate real work from data dumps.

2) Okay, what actually caused Spike #1? 🔍

May 25, 2025 clocks in at ~4.0M (exact: 3,998,050) changed lines (29.0% of the whole period). Most of that is data-ish files (JSON/YAML) and some tests. Here are the heavyweight files that blew up the chart:

Top files by lines changed:

Path	Adds	Deletes	Total lines
packages/xyd-gql/fixtures/-2.complex.github/output.json	2015878	0	2015878
packages/xyd-gql/fixtures/-2.complex.monday/output.json	1896771	0	1896771
packages/xyd-gql/fixtures/-2.complex.github/input.graphql	69424	0	69424
examples/graphql-monday/schema.graphql	6093	0	6093
packages/xyd-gql/fixtures/-2.complex.monday/input.graphql	6089	0	6089
packages/xyd-gql/fixtures/1.basic/output.json	470	229	699
packages/xyd-gql/src/converters/gql-field.ts	347	152	499
packages/xyd-gql/fixtures/4.union/output.json	382	0	382
packages/xyd-gql/fixtures/3.opendocs/output.json	334	0	334
packages/xyd-gql/fixtures/2.circular/output.json	226	63	289
packages/xyd-gql/fixtures/5.flat/output2.json	242	0	242
packages/xyd-gql/fixtures/-1.od_gqls.flat/output.json	177	0	177
packages/xyd-gql/fixtures/5.flat/output.json	177	0	177
packages/xyd-gql/src/utils.ts	78	41	119
packages/xyd-gql/src/converters/gql-arg.ts	66	34	100
packages/xyd-gql/src/schema.ts	85	3	88

3) Top-10 spikes — where does “normal” start? 🧨→✅

I scanned the Top-10 spike days and measured how much came from JSON/YAML (any path) vs tests/fixtures. If the JSON/YAML share drops below 50%, I call it a “normal” spike (less data-dumpy, more code-y).

Rank	Date	Lines changed	JSON/YAML lines (any)	JSON/YAML share	Test lines	Tests share
#1	2025-05-25	3,998,050	3,915,074	97.9%	3,990,595	99.8%
#2	2025-05-26	3,914,637	3,913,711	100.0%	3,914,073	100.0%
#3	2025-06-17	1,208,291	1,203,994	99.6%	1,202,583	99.5%
#4	2025-06-15	1,136,853	1,136,043	99.9%	1,136,045	99.9%
#5	2025-08-01	504,080	419,431	83.2%	353,330	70.1%
#6	2025-07-03	417,164	415,954	99.7%	354,678	85.0%
#7	2025-06-03	387,474	385,791	99.6%	382,974	98.8%
#8	2025-06-11	341,573	338,595	99.1%	333,956	97.8%
#9	2025-06-01	301,086	300,793	99.9%	300,825	99.9%
#10	2025-05-24	155,551	79,612	51.2%	1,261	0.8%

⚠️ All Top 9 still look JSON/YAML-heavy (≥ 50%).

The exact files I muted for the baseline 🧹

Instead of nuking all JSON/YAML everywhere, I muted only the tests/fixtures JSON/YAML files that dominated those spike days. Here’s a preview:

File path (excluded in baseline)	Total lines over range
packages/xyd-gql/fixtures/-2.complex.github/output.json	4,301,630
packages/xyd-gql/fixtures/-2.complex.monday/output.json	3,793,543
packages/xyd-openapi/fixtures/4.abc/output.json	2,315,366
packages/xyd-openapi/fixtures/-2.complex.openai/output.json	678,992
packages/xyd-openapi/fixtures/-3.random/output.json	556,089
packages/xyd-openapi/fixtures/4.abc/input.yaml	205,065
packages/xyd-openapi/fixtures/-3.random/input.json	151,742
packages/xyd-openapi/fixtures/-2.complex.openai/w.json	88,362
packages/xyd-openapi/fixtures/-2.complex.openai/input.yaml	39,860
packages/xyd-openapi/fixtures/-3.random/input.yaml	3,579
packages/xyd-gql/fixtures/1.basic/output.json	3,192
packages/xyd-openapi/fixtures/1.basic/output.json	3,065
packages/xyd-gql/fixtures/6.default-values/output.json	2,857
packages/xyd-openapi/fixtures/5.xdocs.codeLanguages/output.json	2,025
packages/xyd-gql/fixtures/8.example/output.json	1,864
packages/xyd-gql/fixtures/5.flat/output.json	1,315
packages/xyd-gql/fixtures/2.circular/output.json	1,256
packages/xyd-gql/fixtures/3.opendocs/output.json	1,216
packages/xyd-gql/fixtures/4.union/output.json	1,190
packages/xyd-openapi/fixtures/5.xdocs.sidebar/output.json	947
packages/xyd-openapi/fixtures/2.more/output.json	581
packages/xyd-gql/fixtures/7.type-args/output.json	445
packages/xyd-openapi/fixtures/3.multiple-responses/output.json	397
packages/xyd-openapi/fixtures/6.codeSamples/output.json	302
packages/xyd-gql/fixtures/-1.od_gqls.flat/output.json	289

4) Baseline (cleaned) — real rhythm 🧼🎵

Now we re-tell the story without those handful of tests/fixtures JSON/YAML files. Commits don’t change, but line volume becomes way more believable.

Weekday vibe

Figure 2. Adds + deletes by weekday after excluding only the spike-causing tests/fixtures JSON/YAML.

Weekday	Commits	Lines (filtered)
Mon	27	137,104
Tue	26	309,882
Wed	32	288,590
Thu	23	118,749
Fri	32	231,663
Sat	21	363,657
Sun	21	180,215

Cumulative momentum

Figure 3. The long arc of the project with noisy data muted.

5) Cleaned total — still over 1M 🦄

🎉 Even after muting tests/fixtures JSON/YAML, the cleaned total lands at ~1.6M (exact: 1,629,860) (~12% of raw). Not the raw ~13.8M (exact: 13,785,977) churn — but 1M+ cleaned lines is still heavyweight work.

Raw total: ~13.8M (exact: 13,785,977) → Cleaned: ~1.6M (exact: 1,629,860)
Adds/Deletes (cleaned): +~942.2k (exact: 942,203) / -~687.7k (exact: 687,657)
Avg per active day (cleaned): 15,091 lines/day

6) Little extras ⭐

🔥 Longest commit streak: 108 days (Dec 01, 2024 → Aug 19, 2025)
⏰ Favorite commit hours: 23:00 (75 commits), 22:00 (14 commits), 03:00 (10 commits)
📈 Baseline median/day: 3,821 • p90/day: 46,572 • Avg lines/commit: 8,955.3

This was a very busy time for me, but I'm happy that my contribution is in production. If you need a docs framework, let's check it out.

Zero-dep release notes from Conventional Commits

Patryk Zdunowski — Mon, 18 Aug 2025 21:54:05 +0000

If you keep release notes by hand, you know the drill: scroll through commits, group them, paste links, hunt down authors… and lose an hour you’ll never get back.

I wrote a zero-dependency Node script that turns your Conventional Commit history into clean, publish-ready Markdown release notes. It:

Groups commits by type (feat, fix, docs, …)
Detects breaking changes and surfaces Highlights
Appends a short hash with a link to the commit
Resolves a GitHub @handle for the author (PR author fallback)
Works with tags like v1.2.3, 1.2.3, and monorepo-style tags like mypackage@1.2.3

Example, real usage you can find on GitHub releases.

Below is how it works, how to use it, and the full script.

What the output looks like

Here’s a realistic example of the Markdown it prints:

## 🚀 Release v1.4.0

## Highlights
- drop Node 16 support (breaking) by @devin ([a1b2c3d](https://github.com/owner/repo/commit/a1b2c3d))

## Features
- add CSV export to dashboard by @marta ([d4e5f6a](https://github.com/owner/repo/commit/d4e5f6a))
- support OAuth device flow by @liam ([1122334](https://github.com/owner/repo/commit/1122334))

## Bug Fixes
- fix flaky timezone parsing by @sara ([778899a](https://github.com/owner/repo/commit/778899a))

## Performance
- cache user settings lookups by @tom ([99aa001](https://github.com/owner/repo/commit/99aa001))

## Documentation
- clarify env vars in README by @lea ([55cc66d](https://github.com/owner/repo/commit/55cc66d))

## Other Changes
- bump internal tooling by unknown ([abc1234](https://github.com/owner/repo/commit/abc1234))

“unknown” appears if neither the commit nor its PR provide an associated GitHub login (e.g., when the email isn’t linked to a GitHub account).

Quick start

Save the script as scripts/generate-release-notes.mjs (full code at the end).
Provide a GitHub token with repo scope (Actions’ automatic GITHUB_TOKEN works).

export GITHUB_TOKEN=ghp_XXXXXXXXXXXXXXXXXXXXXXXXXXXX
node scripts/generate-release-notes.mjs v1.4.0

Usage

# Basic: between the latest relevant previous tag and HEAD
node scripts/generate-release-notes.mjs <version>

# Explicit previous tag or hash
node scripts/generate-release-notes.mjs <version> <previous_tag_or_hash>

# Explicit range
node scripts/generate-release-notes.mjs <version> <from_hash_or_tag> <to_hash_or_tag>

Tag schemas supported

v1.2.3 (default)
1.2.3
mypackage@1.2.3 (monorepo packages)

For stable releases (no -rc, -beta, etc.), the script compares only against other stable tags. For pre-releases, it compares against the latest matching pre-or-stable as appropriate. If no previous tag is found, it falls back to the repository’s first commit.

Add it to `package.json`

{
  "scripts": {
    "release:notes": "node scripts/generate-release-notes.mjs"
  }
}

Run:

GITHUB_TOKEN=${GITHUB_TOKEN} npm run release:notes -- v1.4.0

GitHub Actions example

Automatically print release notes when a tag is pushed:

name: Release Notes
on:
  push:
    tags:
      - "v*"
jobs:
  notes:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: node scripts/generate-release-notes.mjs ${{ github.ref_name }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

You can pipe the output into a file:

node scripts/generate-release-notes.mjs v1.4.0 > RELEASE_NOTES.md

…and attach it to a GitHub Release or commit it to CHANGELOG.md.

How it works (and why it’s reliable)

1) Repository & range detection

Reads origin remote (SSH or HTTPS) to infer OWNER/REPO.
Figures out previous tag automatically based on your versioning scheme:
- v*, *, or pkg@* (monorepo).
- Stable vs pre-release logic ensures stable tags compare to previous stable.
Supports overriding the range with CLI args.

2) Commit collection via GitHub REST

Calls GET /repos/{owner}/{repo}/compare/{base}...{head} to list commits.
Extracts sha, html_url, commit message, and author login if available.
If a commit author login is missing (squash merges, bots, or non-linked emails), it calls GET /repos/{owner}/{repo}/commits/{sha}/pulls and uses the PR author as a fallback.

3) Conventional Commit parsing

Parses headers like type(scope)!: subject.
Groups into sections (feat, fix, perf, refactor, docs, chore, test, build, ci, style, revert), with a clean title map.
Unknown or non-conventional commits fall into Other Changes.
Anything marked ! or containing BREAKING CHANGE: lands in Highlights.
Final order: common types in a predictable sequence → any dynamic types A→Z → Other Changes.

4) Output

Emits tidy Markdown with section headings.
Each line includes: subject by @handle ([abcdefg](link)).

Edge cases handled

Monorepos: Use mypackage@1.2.3 tags to scope previous-tag detection to that package.
Squash merges: Falls back to the PR’s author handle.
No previous tag: Compares from the first commit.
Non-Conventional commits: Safely grouped into Other Changes.

Customize it

A few quick tweaks you might want:

Change section titles/order: edit TITLE_MAP and COMMON_ORDER.
Hide noise (e.g., chore, style): filter those buckets before emitting.
Change “Highlights” rules: adjust the breaking detection regex.
Write to a file by default: replace the final console.log with a file write.

Full script

Save as scripts/generate-release-notes.mjs and make it executable (chmod +x).

/**
 * Generate release notes with @handles using GitHub REST.
 *
 * Usage:
 *   node scripts/generate-release-notes.mjs <version> [previous_tag_or_hash]
 *   node scripts/generate-release-notes.mjs <version> <from_hash> <to_hash>
 * Env:
 *   GITHUB_TOKEN
 */
import { execSync } from "node:child_process";
import process from "node:process";

const VERSION = process.argv[2] || "";
const PREVIOUS_TAG_ARG = process.argv[3] || "";
const TO_HASH_ARG = process.argv[4] || "";
const TOKEN = process.env.GITHUB_TOKEN;

if (!VERSION) { console.error("❌ Provide version"); process.exit(1); }
if (!TOKEN) { console.error("❌ Set GITHUB_TOKEN"); process.exit(1); }

const sh = (cmd) =>
  execSync(cmd, { stdio: ["ignore", "pipe", "ignore"] }).toString().trim();

// Detect owner/repo from origin (supports .git or not)
const remote = (() => { try { return sh("git remote get-url origin"); } catch { return ""; } })();
if (!remote) { console.error("❌ No 'origin' remote"); process.exit(1); }

let OWNER = "", REPO = "";
{
  const ssh = remote.match(/^git@github\.com:([^/]+)\/(.+?)(?:\.git)?$/);
  const https = remote.match(/^https:\/\/github\.com\/([^/]+)\/(.+?)(?:\.git)?$/);
  if (ssh) { OWNER = ssh[1]; REPO = ssh[2]; }
  else if (https) { OWNER = https[1]; REPO = https[2]; }
  else { console.error(`❌ Not a GitHub remote: ${remote}`); process.exit(1); }
}

// --- Determine range -------------------------------------------------
const isExplicitRange = Boolean(PREVIOUS_TAG_ARG && TO_HASH_ARG);

let BASE = "";
let HEAD = "";

if (isExplicitRange) {
  // version + from + to: honor exactly; skip any tag/version heuristics
  BASE = PREVIOUS_TAG_ARG;
  HEAD = TO_HASH_ARG;
} else {
  // Heuristics only when explicit range isn't provided
  function detectSchema(v) {
    // v1.2.3 or v1.2.3-rc.1
    if (/^v\d+\.\d+\.\d+(?:-[A-Za-z0-9.-]+)?$/.test(v)) return { schema: "v*", prefix: "v" };
    // monorepo/package tag: mypackage@1.2.3 (no slash)
    if (/^[A-Za-z0-9-]+@\d+\.\d+\.\d+(?:-[A-Za-z0-9.-]+)?$/.test(v)) {
      const pkg = v.replace(/@.*$/, "");
      return { schema: `${pkg}@*`, prefix: `${pkg}@` };
    }
    // plain 1.2.3 or 1.2.3-rc.1
    if (/^\d+\.\d+\.\d+(?:-[A-Za-z0-9.-]+)?$/.test(v)) return { schema: v, prefix: "" };
    return { schema: v, prefix: "" };
  }
  const { schema: TAG_SCHEMA, prefix: TAG_PREFIX } = detectSchema(VERSION);

  const firstSha = () => { try { return sh("git rev-list --max-parents=0 HEAD").split("\n")[0]; } catch { return ""; } };

  function latestMatchingTag(exclude) {
    const all = sh("git tag --sort=-version:refname").split("\n").filter(Boolean);
    const isStableVersion = !VERSION.includes("-"); // no pre-release suffix

    if (TAG_SCHEMA === "v*") {
      // v* tags
      return all.find(t =>
        /^v[0-9]/.test(t) &&
        (isStableVersion ? !t.includes("-") : true) &&
        t !== exclude
      ) || "";
    }

    if (TAG_SCHEMA.includes("@")) {
      // mypackage@* tags
      const prefix = TAG_PREFIX;
      return all.find(t =>
        t.startsWith(prefix) &&
        (isStableVersion ? !t.includes("-") : true) &&
        t !== exclude
      ) || "";
    }

    // plain 1.2.x line
    const mm = (VERSION.match(/^(\d+\.\d+)\./) || [, ""])[1];
    if (mm) {
      return all.find(t =>
        t.startsWith(`${mm}.`) &&
        (isStableVersion ? !t.includes("-") : true) &&
        t !== exclude
      ) || "";
    }

    return "";
  }

  const PREVIOUS_TAG = PREVIOUS_TAG_ARG || latestMatchingTag(VERSION);
  BASE = PREVIOUS_TAG || (function () { try { return sh("git rev-list --max-parents=0 HEAD").split("\n")[0]; } catch { return ""; } })();
  HEAD = "HEAD";
}

if (!BASE) { console.error("❌ Could not determine base ref"); process.exit(1); }
if (!HEAD) { console.error("❌ Could not determine head ref"); process.exit(1); }

// --- GitHub REST (no deps) ------------------------------------------
async function gh(path) {
  const res = await fetch(`https://api.github.com${path}`, {
    headers: {
      Authorization: `Bearer ${TOKEN}`,
      Accept: "application/vnd.github+json",
      "User-Agent": "release-notes",
    },
  });
  if (!res.ok) throw new Error(`${res.status} ${res.statusText}: ${await res.text()}`);
  return res.json();
}

async function commitsBetween(base, head) {
  const data = await gh(`/repos/${OWNER}/${REPO}/compare/${encodeURIComponent(base)}...${encodeURIComponent(head)}`);
  return (data.commits || []).map(c => ({
    sha: c.sha,
    url: c.html_url,
    msg: c.commit.message,
    login: c.author?.login || null,
  }));
}

async function prAuthorLogin(sha) {
  try {
    const data = await gh(`/repos/${OWNER}/${REPO}/commits/${sha}/pulls`);
    return data?.[0]?.user?.login || null;
  } catch {
    return null;
  }
}

// --- Conventional Commit parsing & rendering -------------------------
const COMMON_ORDER = ["feat", "fix", "perf", "refactor", "docs", "chore", "test", "build", "ci", "style", "revert"];
const TITLE_MAP = {
  feat: "## Features",
  fix: "## Bug Fixes",
  perf: "## Performance",
  refactor: "## Refactors",
  docs: "## Documentation",
  chore: "## Chores",
  test: "## Tests",
  build: "## Build",
  ci: "## CI",
  style: "## Style",
  revert: "## Reverts",
};
const toTitle = (type) => TITLE_MAP[type] || `## ${type.charAt(0).toUpperCase()}${type.slice(1)}`;
const clean = (s) => s.trim().replace(/\s+/g, " ");
function parseHeader(m) {
  const first = (m || "").split("\n")[0];
  const r = first.match(/^(\w+)(?:\([^)]*\))?(!)?:\s*(.+)$/);
  if (!r) return { matched: false, type: "other", breaking: false, subject: first.trim() };
  const [, type, bang, subject] = r;
  return { matched: true, type: type.toLowerCase(), breaking: !!bang, subject: subject.trim() };
}

// --- Main ------------------------------------------------------------
(async () => {
  const commits = await commitsBetween(BASE, HEAD);

  const items = [];
  for (const c of commits) {
    const parsed = parseHeader(c.msg);
    let login = c.login || await prAuthorLogin(c.sha);

    const bucketKey = parsed.matched ? parsed.type : "other";

    items.push({
      bucketKey,
      matched: parsed.matched,
      breaking: parsed.breaking || /(^|\n)BREAKING CHANGE:/i.test(c.msg || ""),
      subject: clean(parsed.subject),
      handle: login ? `@${login}` : "unknown",
      sha: c.sha,
      url: c.url,
    });
  }

  // Highlights (any breaking / major)
  const HIGHLIGHTS = items.filter(i => i.breaking || /\b(major|breaking)\b/i.test(i.subject));

  // Section order: common -> dynamic types -> other
  const dynamicTypes = Array.from(new Set(
    items
      .filter(i => i.bucketKey !== "other")
      .map(i => i.bucketKey)
      .filter(t => !COMMON_ORDER.includes(t))
  )).sort();

  const sectionOrder = [
    ...COMMON_ORDER.filter(t => items.some(i => i.bucketKey === t)),
    ...dynamicTypes,
    "other",
  ];

  const buckets = new Map(sectionOrder.map(k => [k, []]));
  for (const it of items) {
    if (!buckets.has(it.bucketKey)) buckets.set(it.bucketKey, []);
    buckets.get(it.bucketKey).push(it);
  }

  // Emit markdown
  const out = [];
  out.push(`## 🚀 Release ${VERSION}`);

  if (HIGHLIGHTS.length) {
    out.push("", "## Highlights");
    for (const b of HIGHLIGHTS) {
      out.push(`- ${b.subject} by ${b.handle} ([${b.sha.slice(0, 7)}](${b.url}))`);
    }
  }

  for (const key of sectionOrder) {
    const arr = buckets.get(key) || [];
    if (!arr.length) continue;
    const title = key === "other" ? "## Other Changes" : toTitle(key);
    out.push("", title);
    for (const i of arr) {
      out.push(`- ${i.subject} by ${i.handle} ([${i.sha.slice(0, 7)}](${i.url}))`);
    }
  }

  console.log(out.join("\n"));
})().catch(err => { console.error("❌ Failed:", err.message || err); process.exit(1); });

Final notes

Auth: GITHUB_TOKEN is required; Actions’ built-in token is enough for public/private repos.
Conventional Commits FTW: Consistent commit messages pay off here.
PR authorship: If you squash-merge, the script still credits the PR author.

If you try it, I’d love feedback or ideas for small improvements (like filtering buckets, publishing directly to a GitHub Release, or generating HTML).

Building an Open Source Content Developer Platform for Developers

Patryk Zdunowski — Mon, 18 Aug 2025 20:45:19 +0000

I built Basely, an open-source way to turn React components into images. It’s a developer-first “visual content API”: keep your visuals as components and render consistent assets anywhere you deploy.

Why? I was tired of hand-crafting screenshots and badges for docs, dashboards, and social cards. I wanted something programmable, testable, and repeatable.

You can, for example, render such a component in your README.md:

What it does:

Render React components to images (badges, charts, status tiles, OG images, etc.)
Works in Node, browser, and serverless environments
Pre-built components for common use cases (e.g., a Baseline component for tool compatibility)
Bring your own components + props
Server-side rendering via Puppeteer for high-fidelity output (full CSS/JS, web fonts)

Example use cases:

Compatibility badges (bun/npm/pnpm) in your README
Auto-generated OG images for docs/blog posts
Release notes tiles for Docs/X/LinkedIn
KPI snapshots or charts for dashboards/reports

I've used, for example, Basely to render Node.js Support badge after all e2e tests passed.

How it’s different:

Code is the source of truth
API first

Status & ask:

It’s early, but usable for specific workflows. I’d love feedback on:

If you'd like to use that
Missing presets you’d want out of the box
Video/animation needs (formats/durations/animation patterns)

Happy to answer questions and hear where this would (or wouldn’t) fit your pipeline.

Demo & docs: https://basely.dev
GitHub: https://github.com/livesession/basely