Splitting code into modules

The CredSperiment Initiatives
1

Splitting code into modules

Status: proposal

Champion:

Initiative Description:

Currently we have a “monolith” at https://github.com/sourcecred/sourcecred. Which comes with a number of issues. Especially when trying to build upon or extend SourceCred there will be components you’d want to use as a library.

This initiative is to refactor SourceCred to be split into (NPM) modules.

Benefits:

  • Installation and managing versions will be easier from the user perspective.
  • Reusing SourceCred core code will be easier.
  • Will force making clean APIs at the module integration points.
  • Allows using as a library dependency for example in the UI, widgets, or notebooks.

Implementation plan:

  • Set up a mono-repo, multi-module structure to create and manage the modules from.
  • Bring in several small modules, like the CLI ones proposed for Publish SourceCred on NPM
  • Set up initial shared CI/CD tools that work across multiple modules.
  • Break up sourcecred/sourcecred into several modules. Where at least a “core” comes out of it which we can use as a library.

Estimated Work (hours):

The full scope of work needed to rework all the tooling and refactor code is hard to estimate. But I would be surprised if we can do this within a week.

Dependencies:

References

Contributions:

TBD

2 Likes
2

Question for you, @beanow. You listed Publish SourceCred on NPM as a dependency. But I actually think publishing SourceCred on NPM would depend on this? Are they co-dependencies? Help me understand. :slight_smile:

3

The order could be either way. Both have NPM packages as the end goal.

But modularity is not a requirement for NPM publication. A monolith will publish just fine :] Though a module that’s not published is not really useful.

But the distinction is pretty moot. Perhaps it’s better to merge them?