@ognis1205

By the way, I've re-read the related issue:

#1294

and I’m wondering — is git-cliff actually being used in the development cycle described there?

From my understanding, it doesn't seem like the issue's context involves using git-cliff directly. Could you clarify if I'm missing something?

The limited for git-cliff is not able to run scripts (lua, js etc), and query third-part API to query more detailed information to generate changelog. Compared with introducing a scripting engine for a custom preprocessing stage, adding type info to the existing Context—so third-party tools can handle it more easily—would require fewer changes, wouldn’t it?

For example, if you’re using third-party planning/project-management tools like Linear or Feishu and need to map your journal content (preferably only PRs) to task id and titles in those tools, then using Context with scripting for custom processing is a great fit.

Sry, the generator is internal tool, I cannot share it public.

I don't know of any open-source projects that apply an implementation or operational approach like the one presented in this PR, but I believe there are internal tools that use JSON Schema to validate data type consistency.

I could try generating the schema using build.rs in a designated repository with the method I mentioned earlier. In particular, since the data models in git-cliff-core are expected to vary depending on feature flags (even though all backend feature flags are enabled by default in git-cliff), I think it would make more sense to manage the JSON Schemas in a separate dedicated repository, rather than deriving JsonSchema directly within git-cliff-core.

Yes, I agree with this approach as well. This PR is mainly a prototype for the workflow described above. Publishing it in a separate repository, or bundling it with a Release artifact, would both be good options. External users could use this file to directly generate the Context for the current version. The schema metadata could be provided as a cliff-core feature rather than as a command flag in the cli.

Although I like the changes in this PR, I agree that the output of this CLI command would be too specific to the current release of git-cliff. In other words, it's too dynamic and it might limit our capability to update the context without worrying about user setups that depend on this. We could maybe use a version key, but I believe it will be incremented very quickly if we add/remove/update fields.

I'm not sure how a separate repo would look like for this. Are there any example projects that do that we could get inspired from?

Thoughts?

@orhun

Yes. Cliff is an actively evolving project, and the Context may change quite frequently. There’s no plan to provide stable type guarantees, and introducing a VERSION field to mark versions would be cumbersome. So treating this as something (a) exposed only behind a feature flag, (b) published alongside each release, or (c) maintained as a per-version schema in the repository are all acceptable trade-offs.

Asking users to define their own interfaces to adapt to the Context is too cumbersome and hard to validate—if the type definitions change substantially, it’s difficult for type checkers like tsc or pyright to automatically surface those changes. That would make upgrading cliff versions more painful.