[Meta] Canaries Limited Utility

[phroi]

While I can see that the PR from shouldAddinputs is merged into master, it is not released under canary nor latest. Feel free to check out 0.0.0-canary-20250710073207 and 1.9.0.

Conversely it is present in the older canary: 0.0.0-canary-20250613163026

At this point, I'd like to suggest a couple more ideas for Transaction.completeFee options:

• Instead of shouldAddInputs?: boolean; how about addInputs?: "default" | "disable"; ? (Follows your suggestion of no boolean flags)
• source?: "chain" | "local", this is very evident as it is currently hard-coded to local.

Maybe also consider adding this source?: "chain" | "local" to findCells in Client, we can agree that this missing option is creating quite a bit of unnecessary code duplication in libraries depending on CCC.

Love and Peace, Phroi %18

[Hanssen0]

While I can see that the PR from shouldAddinputs is merged into master, it is not released under canary nor latest. Feel free to check out 0.0.0-canary-20250710073207 and 1.9.0.

Conversely it is present in the older canary: 0.0.0-canary-20250613163026

Hi! The "latest" canary is released from the rgbpp-sdk branch, which doesn't include the new features from the master branch.
As you can see, the canary tag is versioned by date, not semantic version, which means it might include breaking changes/instability. I recommend that anyone using the canary version explicitly specify the version tag, such as 0.0.0-canary-20250710073207, to avoid problems.

[phroi]

Hey @Hanssen0, I'd like to reopen this issue to talk more deeply about the underlying issue:

The "latest" canary is released from the rgbpp-sdk branch, which doesn't include the new features from the master branch.
As you can see, the canary tag is versioned by date, not semantic version, which means it might include breaking changes/instability. I recommend that anyone using the canary version explicitly specify the version tag, such as 0.0.0-canary-20250710073207, to avoid problems.

As you know, we have a few PRs open and a few more coming, this way of handling canaries limit my ability to import our PRs downstream to just a single of these un-merged PRs.

I'd like to easily dogfood our PRs in my projects, but our current canary process doesn't support that. This leads to more bugs & breaking changes leaking into master, which is problematic.

Everything considered, current CCC canaries do not fit my use-case.

My current idea of a workaround is to:

1. Condense iCKB Typescript code to a mono-repo (libs, bot, UI...)
2. Use a semi-automated patching on CCC to apply our PR changes.
3. Dogfooding these changes on a branch, with a local env.
4. Once everything is merged into CCC and published as stable, use that.

About 2 I was thinking about developing some tooling, and who knows maybe it could be useful to others.

@Hanssen0 do you have any feedback/suggestion?

Love & Peace, Phroi %30

[Hanssen0]

I've got no better idea for this. Version releases are branch/commit specified, which means it's impossible to have a release across multiple PRs/branches. Branch merging is required for a release with multiple features.

For 2, I think it is precisely what git is trying to solve. Usually, I create a locall-dev branch and merge/cherry-pick everything I want. If there is no conflict, that should be relatively easy to do.

If you want a canary release for a "fork"/"unstable" version of CCC with specified features, I suggest you open a PR for your local-dev branch. I can accept publishing a canary for that PR.

[phroi]

If you want a canary release for a "fork"/"unstable" version of CCC with specified features, I suggest you open a PR for your local-dev branch. I can accept publishing a canary for that PR.

Hey @Hanssen0, thank you so much for the the availability!! 🥰

precisely what git is trying to solve. Usually, I create a locall-dev branch and merge/cherry-pick everything I want. If there is no conflict, that should be relatively easy to do.

Yesss, exactly, I implemented this using a dedicated pnpm command in the iCKB monorepo:

1. The monorepo root package.json invokes a pnpm preinstall script that imports a specific set of CCC PRs.
2. The preinstall script clones the CCC repo, checks out the specified PR branches, merges them into a single working tree, and runs pnpm to install the resulting package’s dependencies.
3. The cloned CCC is placed under packages/, so it is treated as a workspace member.
4. packages/ccc is listed in .gitignore, so the local clone is not committed to the iCKB repository.
5. The stable CCC package is effectively overridden by the locally built version produced from the specified PRs.
6. The process is reproducible because the script checks out hard-coded PR IDs.
7. This workflow is suitable for local development and testing, provided you do not publish a new iCKB version to the npm registry that references the local clone.
8. For publishing an iCKB release, you must use a final CCC release that includes the PR changes (i.e., a proper CCC version published to the registry).

Phroi %28