(feat) WriteResource includes a draft changelog.md by default

[Jessewb786]

Motivation

I noticed that it was very cumbersome to manually add the changelog.md to resources whether new or versioned, so I'm proposing to include a draft changelog.md that just includes the generation date, so that one can quickly move towards just writing what changed in the changelogs.

Since this seemed to be reasonable to have whether by programmatically calling the sdk or in the generation, I decided to introduce it at the level of the sdk.

Another possibility would be to just expose a addChangelogToResource method in the sdk and then calling it from the generators, but what might be more interesting would be something like addChangelogContentToResource if one wanted to programmatically update changelogs, in which case it would still be reasonable that there be a changelog.md by default.

If you guys disagree, let me know your thoughts. :)

[changeset-bot]

🦋 Changeset detected

Latest commit: 97c4acf

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@eventcatalog/sdk	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[boyney123]

Hey @Jessewb786

Thanks for this!

Hmm that's interesting. At the moment the page just renders empty without change logs, and I think this could be valuable too. In the future I would love the generators to auto generate change log information working out diffs etc too, which could be nice.

Curious what is your current workflow look like?

I do like this idea, but I do also worry abit by randomly added changelogs everywhere for plugins... but... I dont think that is a bad thing!?..... unless others will say so!

[Jessewb786]

Hey @boyney123,

So my current workflow involves first writing/generating with yamlinc a series of asyncapi and openapi specs.
I then run a generate to import all the changed specs into eventcatalog.

I currently don't really have versioning setup for the domains, it's always 1.0.0, but I hope to eventually do proper domain versioning.

What happens now, as a consequence of the above, is that in each domain I need to manually clean out the old service versions, because the new ones just get appended.

Then I have to go generate all the changelogs, the cumbersome part I was hoping to improve.
Sometimes I add a message here and sometimes not, because the auto-generated diff passes the message along clearly, like if it's just a description change or something.

Then perhaps filling in any missing details of a service or the domain, etc.

And in parallel, I use those same specs from earlier to generate a bunch of controllers, clients, producers and consumers.

One thing in Event Catalog that makes its absence known is the lack of Data Store information.

In cases where one service on the write path writes to a DB and another on the read path reads from it, these two services show up as basically unrelated.
Or sometimes a service may read a .csv file from some Kubernetes Persistent Storage, but I can't present it in the diagrams. So I'm relying on the service markdown to document that kind of information.

It would be nice to also have page for each Data Store.