Skip to content

feat: resolve project-id and org-id using instance-id#38

Open
LucDeCaf wants to merge 11 commits into
mainfrom
feat/optional-id-params
Open

feat: resolve project-id and org-id using instance-id#38
LucDeCaf wants to merge 11 commits into
mainfrom
feat/optional-id-params

Conversation

@LucDeCaf
Copy link
Copy Markdown

@LucDeCaf LucDeCaf commented Apr 14, 2026

Replaces #37 using a cleaner and (hopefully) simpler approach.


Using a newly introduced path in @powersync/management-client, automatically fetch the project_id and org_id flags when given the instance_id for a number of commands (where it makes sense to do so).

Example

Before:

powersync pull instance --project-id='project-123-456-789' --instance-id='instance-123-456-789'

After:

# Project ID is fetched from the management service if required
powersync pull instance --instance-id='instance-123-456-789'

AI Usage

Claude Code was used to update documentation and examples to reflect the new paths. It was also used for simple edits/refactors (e.g. moving a constant to be exported from a shared file).

Comment thread cli/src/api/cloud/validate-cloud-link-config.ts Outdated
Comment thread packages/cli-core/src/utils/resolve-cloud-instance-link.ts Outdated
Comment thread cli/src/api/cloud/validate-cloud-link-config.ts Outdated
@LucDeCaf LucDeCaf marked this pull request as ready for review May 25, 2026 11:29
Copy link
Copy Markdown
Collaborator

@stevensJourney stevensJourney left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like it's going in a good direction. I'm happy with the implementation so far.

I left a few minor comments on some lines which stood out.

I think the main outstanding item currently is that of docs: both externally in our powersync-docs site (and agent skills) and here in the various README and docs files. We should update all references to commands which no longer need to supply the org/project IDs.

For commands where it's possible, I think we should steer people away from using the org/project IDs. If we removed the flags, that would be a breaking change as previous command invocations would fail - I'm not sure if there is an easy way to have the field be accepted, but be ignored. At the very last, I think we could mark those fields as deprecated.
It could be that carrying those fields makes things more confusing than just removing them, in which case it could be justified to make a breaking change and remove them.

Comment thread packages/cli-core/src/utils/resolve-cloud-instance-link.ts Outdated
Comment thread packages/cli-core/src/command-types/CloudInstanceCommand.ts Outdated
@benitav
Copy link
Copy Markdown

benitav commented May 25, 2026

I think we should steer people away from using the org/project IDs. If we removed the flags, that would be a breaking change as previous command invocations would fail - I'm not sure if there is an easy way to have the field be accepted, but be ignored.

Agreed, ideally they can just be ignored

@LucDeCaf
Copy link
Copy Markdown
Author

LucDeCaf commented May 26, 2026

Currently the CLI still accepts project-id and org-id and uses them as manual overrides (provided both are supplied). I think eventually we'll remove the options entirely in order to simplify the codebase (maybe a few versions down the line).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants