search

multinet-app / multinet-rfcs

A collection of proposals for Multinet development
0 stars 0 forks source link

RFC: Autopublishing for MultinetJS #8

Closed waxlamp closed 4 years ago

waxlamp commented 4 years ago

One of the active pieces of software driving the Multinet project is multinetjs, a TypeScript library providing clientside bindings and utility functions for the Multinet API. This software grows with the needs of the project, specifically of the Multinet client. This means that often, a new feature in the client requires a new feature in MultinetJS, and to support this use case, this RFC lays out a plan for more easily publishing prerelease and development versions of the library for use in client development.

rendered

subdavis commented 4 years ago

This is an interesting idea. I'm not sure I fully understand how it would work or what the implications are.

If I'm working on multinet-client that requires an un-merged feature in multinet-js and the goal is to get CI to publish client as a preview to netlify, how do I tell client about that un-merged branch's NPM prerelease? Do I have to update package.json in client by hand after every successful prerelease of multinet-js?

waxlamp commented 4 years ago

This is an interesting idea. I'm not sure I fully understand how it would work or what the implications are.

If I'm working on multinet-client that requires an un-merged feature in multinet-js and the goal is to get CI to publish client as a preview to netlify, how do I tell client about that un-merged branch's NPM prerelease? Do I have to update package.json in client by hand after every successful prerelease of multinet-js?

The short answer is "yes".

In my view of the common case, you would do some work on multinetjs (perhaps several commits' worth) to create a new feature there, then manually change the dependency in multinet-client to match the prerelease package for the appropriate multinetjs commit. (I would likely include an NPM script in multinetjs so you could get the appropriate version string by running yarn prerelease-version or something like that.)

In the common case, you'd only have to do this once. If you had a strange situation where you needed to iterate on multinetjs based on what was going on in multinet-client (I can't even imagine a hypothetical case where this would happen, though I'm sure it would eventually), then you'd have to do a lot of manual updating and yarn installing.