Allow Running Custom Commands Per "Lifecycle"

Affected Packages

Extent not quite known.

Problem

We are hoping to use changesets in a polyglot monorepo. We have multiple packages with multiple languages (Rust and js at the current moment.) Obviously we are unable to version, generate changelogs and publish Rust.

Proposed solution

I believe we could abstract out the commands that are run at the various “lifecycles” and allow them to be configured. We would set the default commands to be the existing functionality for backwards compatibility. This would solve our dilemma as we could run the Rust commands instead which mirror the current functionality. This would also allow other cases such as #171.

This would also allow changesets to expand outside of js-land. With GitHub Actions and the bot, a pure Rust package could use changesets through the automation and never need to install node. A simple script to create the markdown file could be created, or it can be done manually (or strictly through the bot).

If there is interest for this, I would be willing to tackle a PR for it.

[jbolda]

@JakeGinnivan I’ve created a library with polyglot support and arbitrary commands as similarly described here. It sounds like it would applicable to your use case. Happy to discuss further and always love code/docs help. /cc @ryaninvents

https://github.com/jbolda/covector

I am going to close this as it will not be a supported use case in changesets.

[emmatown]

Hey folks, sorry to do after all this work has been put in but @Noviny and I have talked about this and we don’t think that building support for Rust/this sort of extensibility in general into Changesets is best for the project.

The reasoning being that it creates so many questions that we don’t want to have to answer(e.g. what happens if there’s a Rust package and a JS package with the same name? What happens if there’s a dependency between a JS and a Rust package? How does updating dependents work with Rust packages?) and the problem with that isn’t about finding answers to these questions, it’s that adding Rust support means that we have to answer these questions where we previously didn’t and even if we did answer all these questions and the others that would come up, Rust support constrains what we can do in the future and right now, our primary goal with Changesets is to provide a great experience for versioning JS monorepos and if we are trying to support Rust as well, we won’t be able to spend as much time on supporting JS monorepos so we’ll have a worse project. We definitely should be clearer about this in our documentation though.

With all that said, if Changesets can help people manage Rust packages as well without constraining Changesets, that’s great! So what that means is that, for now, the best solution is going to be @ryaninvents approach of building on top of Changesets and potentially sometime in the future when all the behaviour is figured out, it might make sense to move it into Changesets itself(though this is very much a maybe thing though, we don’t believe building support into Changesets itself isn’t an inherently good thing). There are also a bunch of ways you could improve this outside of Changesets like generating the package.jsons for Rust packages and etc.

I should also note that when I’m referring to Changesets here, I’m referring to Changesets-the-tool rather than Changesets-the-idea, Changesets-the-idea is definitely something that transcends a particular language ecosystem though Changesets-the-tool, for now, isn’t.