Sigma.js packaging about sigma.js HOT 6 CLOSED

Here are some thoughts:

• I don't like having to push a sigma version to fix a node-image-program bug
• I would like more features to be hosted on this repository, such as curved edges for instance
• I wouldn't want these new features to be packaged with sigma

So, I'm sure it would be better to split like you say. I agree with having a sigma package that is more plug-and-play (though I think I would like to move node-image-program outside of it). For the rest, @sigma/core makes sense to me, @sigma/node-image-program as well (and hopefully @sigma/edge-curved-program sometime). For @sigma/default-programs I don't know I prefer this or @sigma/node-circle-program, @sigma/edge-arrow-program, etc...

Another aspect to consider is how we want the repository to be organized. The current src files structure is kinda weird (having programs altogether in a folder, then all shaders in another one, rather than having one directory per program).

from sigma.js.

My points, in "vrac" (I did not re-read the whole discussion so they might be moot or redundant):

• We should keep a monorepo structure for stuff that need to benefit from functional testing, so we don't duplicate the complicated stack it requires. I don't know what's the go-to utility to deal with monorepo easily these days. I tend to somewhat use lerna but I think it is not maintained anymore.
• The sigma package should remain the main installation target, for convenience and backwards-compat (v3 is mostly aligned with v2 if you don't develop custom rendering anyway). It can be a compilation of other subpackages indeed. I don't really see the value in "over" splitting the core of the library into a core, renderers, camera etc. since we don't envision supporting something else than an interactive webgl renderer.
• I agree that the @sigma scope vs. sigma- prefixed packages means we can control the scope against potential squatting (the expression is a bit harsh lol)

from sigma.js.

OK, so here is a plan:

• Split codebase into a multi-packages repository (something similar to what @sim51 did in react-sigma, with sigma, examples, demo and website
• Move edge.triangle into the custom-rendering example (I'm sure nobody uses it, partly because without anti-aliasing it makes things awful to read)
• Move node.image as a new node-image-renderer package (still in the same repo)
• Update documentation about how to release etc..

Then, the packages we would have would be:

• sigma (same as today, but without edge.triangle and node.image
• @sigma/node-image-renderer, with the current version of the factory (then we should add proper testing, and port some of @Yomguithereal's take on it)

And for later, we could add @sigma/edge-curve-renderer and @sigma/image-export for instance.

from sigma.js.

WIP on branch v3-packages

• Demo has been migrated to latest version of react-sigma, but it remains the label renderer and the graph button style
• Example : example that need a custom program or a hover/label render need some modifications

from sigma.js.

• Redo label renderer on demo
• Review README
• Review examples with custom program
• Review examples with node hover/label render

from sigma.js.

I close this ticket since it's mostly done, and the remaining tasks haven't been discussed here yet.

from sigma.js.