remove js and go package and probably move json schemas should stay alone in the repo

[derberg]

#124 introduced symetric releases for the package. So basically whenever there is a change in Go package, we will also release JS package in all the different projects that depend on it. Cause a lot of noise with "empty" functionality.

1. Go package should have its own release cycle. Symetric releases are cool but for cases like in react-component where we release web-component and other things at the same time
2. I know some time ago we took JSON Schema files out from spec repo and moved it here to have one project with JSON Schemas and projects for different languages. But I admit, that in this discussion I never took into consideration release process and how strange things will work here. IMHO the best would be to leave JSON Schemas in this repo alone, then JS code should go to js-json-schemas and Go should go to something like go-json-schemas. Once JSON Schema is released with some update, there should be a workflow that pushes updated json schema to JS, Go and other projects and release is triggered there automatically

Related conversation: #118

[derberg]

@fmvilas @smoya have a look

[smoya]

I wasn't very conscious about the fact we have so many dependents on this right package: https://github.com/asyncapi/spec-json-schemas/network/dependents.
Releasing a new version of it, without real changes that affect the package you depend on, is definitely not something ideal; such as getting an update of the node package triggered by a Go code change.

On the other hand, the idea of having all language implementations in the same repository introduces few interesting benefits:

• Test suites for each language implementation run on every PR that introduces changes on the schemas, meaning whatever you merge, it is supported by all different implementations. I have to say that with current implementations, I would not expect something to get broken whenever we introduce changes on the schemas (we mostly create new files, right?) but not sure how each package will evolve in time.
• Packages for each language implementation are automatically released whenever we introduced a change on the schemas VS having to create a PR on each implementation repository, review it, accept it and merge it (feature disparity will happen across languages). We could automate this? I think so, but it is an extra effort and could eventually fail (tests could fail, related to what I mentioned earlier).

It is fair if we want to think deeply about it and decide what do we want to leave behind, as as far as I can see, there is no silver bullet.

[fmvilas]

Can't we have a monorepo in this case? I mean, what would we need to make releases work depending on the directory that has been modified? Just curious.

[smoya]

Can't we have a monorepo in this case? I mean, what would we need to make releases work depending on the directory that has been modified? Just curious.

For languages with proper package registries, it is easy because you have to manually push the package to the registry (such as npm). However, languages such as go that directly pull from source based on tags is a bit more tricky.

However, it can be done (TIL) as Go doc says at https://go.dev/ref/mod#vcs-version

If a module is defined in a subdirectory within the repository, that is, the module subdirectory portion of the module path is not empty, then each tag name must be prefixed with the module subdirectory, followed by a slash. For example, the module golang.org/x/tools/gopls is defined in the gopls subdirectory of the repository with root path golang.org/x/tools. The version v0.4.0 of that module must have the tag named gopls/v0.4.0 in that repository.

So I see adding the subdir as prefix of any tag would work for any language as they will match language implementation.

Any cons I'm missing on this @derberg ?

Btw, there is tooling out there that could help. Afaik Bazzel is one of them (never used).

[derberg]

I'm not proposing monorepo because of the git tags and github releases reasons. We would simply need to introduce some new "workflows" just for one repo:

• git subdirectories that we did not use so far in any AsyncAPI repo
• Bazzel 😨
• prefixes for tags

So we add complexity with no real benefit.
We already have experience with no-monorepo approach, auto bumping, updating stuff that was changes from repo A in repo B (TSC list, specification autoupdate in website, even on release candidates)

Test suites

it could be benefit, but it is also doable without monorepo. We need to figure it out anyway for generator (would makes sense to have integration tests on generator that check some selected templates, we actually have some super basic ones) or for parsers (that are not monorepo, parser-js and parser-go are separate and at some point of time we anyway need them to run against project delivered by tck repo)

Packages for each language implementation are automatically released whenever we introduced a change on the schemas VS having to create a PR

As I wrote already, this problem is already solved in a few repos (it is all about cloning, copying files and opening a PR https://github.com/asyncapi/community/blob/master/.github/workflows/update-website.yml). GH Actions rock, and we have already a workflow with bots merging PRs created by bots.

---

also you might not be aware but we had some headaches with semantic-release in react component repo that is monorepo. And here we would even have bigger issues, and a we would need to research best way to do it as for node projects we operate using semantic-release through package.json and in case of go it is semantic-release config file.

---

I know we are getting more and more granular on repo level here, but again - we know how to handle it like a pro already and we do not have to worry about anything when more languages will come, like java

Thoughts?

[fmvilas]

Thoughts?

Kill monorepos with fire 🔥

I just wanted to make sure it has been considered but yeah, it's a ton of work for not much benefit.

[derberg]

@smoya did I convince you?

[smoya]

@smoya did I convince you?

I am not 100% convinced because I really see having a whole integrated testsuite, without the need of any arcane magic, is a clear benefit (and I would say a must).
However, I really see that magic should happen in any of the strategies we choose, so I am not leaning towards any solution at this time.
We can move forward by splitting into several repositories. In case it ends up not working as desired, we could reconsider it again, right?

So I guess you have my +1 😅

[smoya]

I'm up for moving this forward so I want to create a new repository spec-json-schemas-go but I have no permission to do so anymore.
I guess only @derberg and @fmvilas can now, so I'm summoning you 🪄 ✨

In the meantime anyway there are more things to work on, such as the script to keep schemas up-to-date on repositories.

[derberg]

I'm not sure we should do it now. Next release is planned for January, it is a first time we have new release coordinator, lots of work ahead. I just propose that we do it after release. Thoughts?

[smoya]

I'm revisiting this issue and rethinking it. I want to discuss about:

Releasing a new version of it, without real changes that affect the package you depend on, is definitely not something ideal; such as getting an update of the node package triggered by a Go code change.

This should not happen usually. In fact, I would say it will potentially only happen when we release the go package. After that, only when new Spec releases happen (as much because we can build it to not depend on this and work directly with the schemas so we won't need to update the package when new schemas are added).

My question is, is it worth all the effort we were suggesting here (split all language implementations to be on their repo + sync schemas)? I think not. Look at how much time it passed and we didn't have the bandwidth to work on this. There are people interested in using the parser-go but we are kinda blocked on this for supporting new versions.

I would say the impact on releasing potentially just one package can be worth if it removes all the efforts of this ticket.

I know we discussed this, but wanted to give it a thought again.

cc @derberg @fmvilas @magicmatatjahu

[derberg]

my understanding was that it is delayed not because of lack of bandwidth but just because we did not want to do it before January and now we have this big change coming in with schema split, so better do restructuring once it is in place, as whatever script we would have here to push out JSON Schema, it would anyway need to be refactored for the schema split PR. At least it was my understanding.

There are people interested in using the parser-go but we are kinda blocked on this for supporting new versions

I don't get why this issue is blocking folks from using Go Parser? go module with JSON Schema is already released, right? then we just need to update the dependency reference? or am I missing some Go-specific details??

[smoya]

go module with JSON Schema is already released, right? then we just need to update the dependency reference? or am I missing some Go-specific details??

It is not working due to the missing module prefix. See #126.

[derberg]

actually in my opinion #126 should not wait for this issue. Just Go parser will need to update references once we do refactoring of this repo

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️