chore(github-actions): configure commitlint to lint the PR title

[fhennig]

#1057 (not completely resolved: we want to only allow squash-merge)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
dashboard-components	Error		Jan 12, 2026 9:42am

[github-actions]

There is no change in the changelog. This PR will not produce a new releasable version.

[fengelniederhammer]

Thanks, that was easy!

I think it would be good to adapt the docs in CONTRIBUTING.md to say that only the PR titles need to follow conventional commits now.

[fengelniederhammer]

There is also

    "commitlint:last-commit": "commitlint --from=HEAD~1 --verbose",
    "commitlint:merge-base": "commitlint --from=$(git merge-base HEAD main) --verbose",

in the top level package.json which isn't really necessary anymore. I'm undecided whether to leave it or remove it. What do you think?

[fengelniederhammer]

There is no change in the changelog. This PR will not produce a new releasable version.

I also wonder how useful this will be... Is there an easy way so that we could still get a changelog preview?

[fhennig]

I think I'd remove the two commands, I haven't used them before. Same for the changelog preview.

Maybe the changelog preview could be modified so it does a merge with the PR title to generate the changelog? But there might be merge conflicts. Or maybe there is another way, we could investigate this; but I would just drop this action, personally.

@chaoran-chen what do you think?

[fengelniederhammer]

Maybe the changelog preview could be modified so it does a merge with the PR title to generate the changelog? But there might be merge conflicts. Or maybe there is another way, we could investigate this; but I would just drop this action, personally.

It has been quite useful sometimes (admittedly more when we were new to release-please). Especially for breaking changes it's nice to see how the changelog turns out when you want to write a proper message for breaking changes. But I'd be open to delete it for now.

[chaoran-chen]

As Fabian said, the preview can be quite useful for people who are not very familiar with the system especially in more complicated cases with breaking changes, but I don't think that it's critical to maintain/adapt it if it takes significant effort.

[fengelniederhammer]

As Fabian said, the preview can be quite useful for people who are not very familiar with the system especially in more complicated cases with breaking changes, but I don't think that it's critical to maintain/adapt it if it takes significant effort.

If something is merged to main that doesn't have the expected changelog, it can still be changed manually in the PR and in the GitHub release. Losing the preview in the worst case means some manual extra work.