How to depend on sourcecred and widgets

[Beanow]

Right now, update scripts and depending on sourcecred + widgets is enough work to be contained in a repo of it's own. A simpler way to have sourcecred as a dependency would be great.

For example, having NPM packages for them and a smaller footprint scaffold to run updates.

[Beanow]

From #2 @decentralion

It adds some complexity (e.g. we need babel to remove the flow types, probably need webpack too).

Part of why I didn't include much precompiling complexity just yet is because of this issue.
I think the eventual build target for this should probably be as an NPM package that has some binaries you can invoke. Perhaps even in a library style so you can add your own filtering logic and take control over the widget generation.

And while they can be precompiled for NPM packages it comes at a high debugging and hackability cost, because the output you would be distributing is generally not legible.

[teamdandelion]

Yeah, we should get the core sourcecred CLI published on NPM. I've made an issue about it here: sourcecred/sourcecred#1232.

Yeah, publishing this library-style with binaries makes sense. If we do go the babel+webpack route, we could publish concatenated but non-minified source, and that would still be pretty legible. I suspect we could find a way to use babel and not concatenate the source, but I'm not sure.

However, while this project is really small, and while it doesn't directly depend on sourcecred source, maybe there isn't a huge need for flow typing. Ideally, once we publish sourcecred as a library, we'll refactor widgets to depend on sourcecred at the js-API layer rather than the CLI layer. At that point, having flow types will be really valuable.

[nothingismagick]

I totally agree with publishing at NPM. Submodules work - but they tend to be brittle and generally only useful (IMHO) when something is bulletproof and not being iterated on.

[Beanow]

Related: #36 #35

[Beanow]

I think both NPM and Docker packaging and improved CLIs are the currently planned routes. So I'll close this in favor of the above links.