Support For Other Languages

[han-tyumi]

Is there any interest in expanding this to support other languages / ecosystems?

I would love to be able to carry over the core specification and CLI without the Node ecosystem leaking in by requiring a package.json to be e.g., in my Golang project.
This became even more apparent to me when developing with Deno.

This is something I appreciate with conventional commits - I can use a tool like cocogitto along with any language I like.

[Andarist]

If this can be done within bounds of reasonably added complexity - then sure, ye. I personally don't have time to develop this though. I also don't think that package.json itself is something to be concerned about here, after all... we need to store this kind of information somewhere and package.json can be treated like a config file just like any other. It has a special meaning in the node/JS ecosystem but other than that it's just some structured format that can be used in other contexts as well.

[han-tyumi]

@Andarist Thanks for the reply!

I suppose I could get over dealing with package.json elsewhere haha.
I would just prefer to see that information stored exclusively for changesets itself - likely in the .changeset/config.json.

This way...

• there aren't two additional config files when being used with another language.
  • One at the root and one in .changeset (isn't apparent they are linked when in the context of another language).
• all configuration can be stored in one place.

I'll see about creating a PR that allows also specifying that information within .changeset/config.json - either giving priority to package.json if it exists or overriding it.
From a quick look, it looks like only the "name" field is used.

Perhaps a better option would be to allow specifying the file to pull the package name from perhaps through specific language adaptors etc.
However, obviously some more complexity there.

[han-tyumi]

Well, taking a closer look, I can see that this would be more difficult to do than I anticipated 😆.
I'll still try to take a stab at it however.

[StephenStrickland]

Would also be interested in this as well. Our team has several codebases in different languages (several non JS), it'd be great to standardize release management.