Where to publish packages?

[joekrill]

The kit is setup as a monorepo of individual packages. This is intentional so that we can upgrade individual components and packages with minimal impact throughout the rest of our codebase (and to allow the consumer to decide when and how to upgrade). Because of this, the ideal scenario is that these get published to a package registry like NPM, then they can be consumed by simply adding that in the "standard" way using the package.json's dependencies section, i.e.:

{
  "dependencies": {
     "@pearkit/icons": "~1.0.0",
  }
}

The easiest route would be to simply deploy to NPM. By default, however, that would make these packages public (is that really a problem, though?) Other options would be:

• Pay for a private repos at NPM. We'd have to pay per-user, though, I believe, @ $7 per user per month.
• Use Github to reference the code directly. This isn't super-straightforward with a mono-repo. We could certainly make it work, but it wouldn't be super-straight-forward. It may be possible to use Github's "releases" somehow, but I haven't really come across a way to do this easily. Github is coming out with their own actual registry, but it's in beta at the moment and has limited availability (and eventual pricing is unknown).
• Run our own private repo in our infrastructure using something like Verdacccio.

Is using public NPM packages acceptable. We can deploy it in a very minimal way, without any related documentation or anything. But someone could technically use our components if they really wanted to. I don't particularly see the harm in it, but that's not a really a decision for me to make.

[hansent]

+1 on public npm package

[joekrill]

Everyone seems good with using public NPM, which will make this much, much simpler. @floatingboxes had some concerns around our illustrations (Kate Moore's art) being published here, though, so let's avoid that for now.

We can also consider open-sourcing the code at some point. I think just knowing that the code is (or could be, soon) "public" leads to better code quality, too, to some extent!