feat: resolve project-id and org-id using instance-id#38
Conversation
stevensJourney
left a comment
There was a problem hiding this comment.
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.
Agreed, ideally they can just be ignored |
|
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). |
Replaces #37 using a cleaner and (hopefully) simpler approach.
Using a newly introduced path in
@powersync/management-client, automatically fetch theproject_idandorg_idflags when given theinstance_idfor a number of commands (where it makes sense to do so).Example
Before:
After:
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).