I thing you are doing a very subtle mistake which will become fatal in long-term. Your strategy to take small steps that cover as much functionality as possible is reasonable, but it is necessary to be careful, as it leads to a critical state when there is too much little stuff built up without proper structure to support it.

When the relations are implemented in the right way, they will simplify Gitlab, not make it more complex.

Another example are issue boards. They represent elegant use of a good infrastructure ­— it is all just a smart use of labels. It would be very complex feature without the use of labels.

Issue relations are meant to be the basic infrastructure to build on (at least that is how I meant it when I posted the original feature request). Just like the labels are just a binary relation between a issue and a "label", the relations should be just a ternary relation between two issues and a "label". Then you can build issue task lists on top of the relations like you've built issue boards on top of the labels.

Yarn has stated before that the goal of Yarn Workspaces is to provide low-level primitives for tools such as Lerna to use, not to compete with them.

What's a primitive?

What's an object (i.e. not a primitive)?

Provides a bunch of primitives to write declarative business logic

I think the main difference between the two are the way API are served. Some smelte components need you to input big chunk of json as props, while i prefer keep props as primitive types and in the other hand give you different components tags to compose.

On one hand Solid just provides a collection simple primitives like createState, createEffect, createMemo, etc.. These can be composed to create much more powerful behaviors.

I couldn't land on how I wanted to box primitives. Should I use a getter/setter, or function form like Knockout, or explicit get/set like MobX? These were all ugly.

This was the easiest way forward until this lib integrates with the Sapper primitives.

Physical texts were already massively addressable before they were ever digitized, and this variation in address was and is registered at the level of the page, chapter, the binding of quires, and the like.