[Feature]: Skip prompts when using shopify app config link -c with existing config
What area(s) will this request affect?
App
What type of change do you want to see?
New feature
Overview
Improve the behavior of shopify app config link -c <configName> so that when an existing .toml file is specified, the CLI refreshes or updates the file directly without prompting for organization or app selection again.
Following up on: https://github.com/Shopify/cli/issues/6202
Motivation
Currently, even when using the -c or --config flag to target an existing config file, the CLI proceeds through the full interactive flow (org selection, app linking). This is repetitive and inefficient, especially for developers working across multiple devices or syncing environments. Supporting a streamlined update flow when the target config already exists would make link much more useful and aligned with developer expectations.
Hey @muchisx, I don't quite understand, the whole point of config link is selecting a new app (in the same or a different organization). What would you expect for this command to update if not that? It doesn't update anything else in the toml 🤔
Hi @muchisx --
I think what you are asking for is a way to sync the remote config to an existing shopify.app.toml. Maybe something like shopify app config pull would be better for that? 🤔
I'm curious about your workflow though -- are you and your team often making changes directly in the dashboard, vs making them in the toml and running deploy? Can you tell us the reasons why?
Hi @isaacroldan @nickwesselman !
Thank you for the feedback!
@nickwesselman
I'm curious about your workflow though -- are you and your team often making changes directly in the dashboard, vs making them in the toml and running deploy? Can you tell us the reasons why?
Here's my workflow:
- In
.gitignorewe haveshopify.app*.tomlbecause:- We are multiple devs and and we don't want to commit all of the dev apps tomls
- We do not want any dev connecting/running dev to the production app by mistake, so we do not commit it either.
- When we do productions deployments we need to make sure the production
app.tomlis up to date (because it's not committed). Most of the times it can be that a scope is in production but not in local, because we might deploy from different devices. - So before deploying we always run a
config:linkfor the production config, just to make sure we won't be deleting/removing any scopes or configuration that were introduced from other devices. - Lastly, the reason for the PR is that since the toml is already in the PC, we just need to pull/update some values that might be stale (as you suggested with the
pull), without going through the processes of selecting which org, which app, etc... Just with the config name.
I agree that a shopify app config pull command would make more sense.
Alternatively, you can run shopify app config link --client-id XXX to skip the prompts about org/app. @muchisx Maybe that's enough for your use case?
Hi @gonzaloriestra a human readable --config would be better (through the config pull proposal sounds good!) The client ID requires I remember the IDs of all apps, but I'll give it a try, thank you !
This issue seems inactive. If it's still relevant, please add a comment saying so. Otherwise, take no action. → If there's no activity within a week, then a bot will automatically close this. Thanks for helping to improve Shopify's dev tooling and experience.
P.S. You can learn more about why we stale issues here.
Hi there, should I create another request for a config pull command or keeping this one makes sense?
@muchisx we agreed internally that config pull would be the right solution here. So if you want to open a PR, it would be much appreciated and we would review it.
Otherwise, it's in our backlog, but I can't give you an estimation... The priorities change too often 😅
Hi! I'm interested in working on this feature and implementing the proposed config pull solution. If no one is currently working on it, I’d love to take this issue and open a PR. Please let me know if that’s okay!
Hi @anakafeel, that would be great, thanks a lot. Once you have it ready, or a draft, I can have a look.
Hi @anakafeel, that would be great, thanks a lot. Once you have it ready, or a draft, I can have a look.
Hi! I've opened a PR implementing this change: #6662
It skips the interactive prompt when --config points to a config that already contains a valid client_id, while keeping existing behavior unchanged otherwise.
Happy to iterate or adjust if needed,thanks for the guidance!
@anakafeel thanks a lot for opening the PR! Unfortunately, that's not the expected approach, sorry if we weren't clear enough.
The link command with --config should function as pre-filling the file name prompt, but still fully prompt for org and app, even if it’s an existing config.
The solution I mentioned here is about adding a new shopify app config pull command that would pull only for the current config (or the selected one with --config), using always an already-linked org and app.
@gonzaloriestra Thanks a lot for the clarification.
I see now that changing the behavior of shopify app config link --config isn’t what you’re aiming for, and that the desired solution is a separate shopify app config pull command that reuses an already-linked org/app.
I’d be happy to rework this PR to implement config pull as you described and reuse some of the helper logic I added here (e.g. resolving the remote app from the existing config). If that sounds good, I’ll start by reverting the link behavior change and then move the logic into the new command.
Perfect, thank you!
Hi @gonzaloriestra ,
I've updated this PR to follow the correct approach you described.
Instead of modifying the behavior of shopify app config link --config , the PR now introduces a new shopify app config pull command that:
-Detects the selected config (or the one passed with --config) -Validates that the config contains a client_id -Uses the already-linked org/app to resolve the remote app -Pulls the remote app info without any prompts -Leaves the existing link behavior completely unchanged
I reverted the previous changes to the link flow and moved the logic into the new command as suggested. it took me a bit to understand the codebase, but this approach feels much cleaner :)