What
we want preview packages, likely for commits in prs and latest in main
pkg-pr
not a great solution as they have size limits which our larger sdks push on and the workflows seems to be really rough when we publish multiple packages at the same time. multiple packages is maybe fine sinc once we stabilize it should be mostly 1 or 2 packages per pr
tagged npm
probably fine but it might clutter our npm, we might have issues deleting tags if we want to do that?
github packages
big downside is the command to install is a little ugly: npm install @your-org/your-pkg@0.0.0-pr-123.abc1234 --registry=https://npm.pkg.github.com
and we can't scope the package org to distilled.cloud unless we also move the org and it seems messy with monorepos since even if we do move orgs we could still at best be taking up namespace
making our own
wen alchemy-effect
Questions and Misc Info
- Do we want to delete pr/commit packages when the pr gets merged (or pr merged + 7 days or something)?
- Do we care about npm clutter?
- we should keep in mind that if we push tagged to github it will make the next non-tagged have a partial changelog since we only check from last tag IIRC
What
we want preview packages, likely for commits in prs and latest in main
pkg-pr
not a great solution as they have size limits which our larger sdks push on and the workflows seems to be really rough when we publish multiple packages at the same time. multiple packages is maybe fine sinc once we stabilize it should be mostly 1 or 2 packages per pr
tagged npm
probably fine but it might clutter our npm, we might have issues deleting tags if we want to do that?
github packages
big downside is the command to install is a little ugly:
npm install @your-org/your-pkg@0.0.0-pr-123.abc1234 --registry=https://npm.pkg.github.comand we can't scope the package org to distilled.cloud unless we also move the org and it seems messy with monorepos since even if we do move orgs we could still at best be taking up namespace
making our own
wen alchemy-effect
Questions and Misc Info