Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor CLI command runner #708

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

aswamy
Copy link
Contributor

@aswamy aswamy commented Jan 14, 2025

What are you adding in this PR?

Follows up comment by @madmath #597 (comment)

Refactor our metafields pull command into a proper CLI command runner

Before you deploy

  • I included a patch bump changeset

@aswamy aswamy requested review from madmath and charlespwd January 14, 2025 19:50
@aswamy aswamy requested a review from a team as a code owner January 14, 2025 19:50
@aswamy aswamy force-pushed the refactor-cli-command-runner branch from 412a06c to 18d4a09 Compare January 14, 2025 20:19
Copy link

@madmath madmath left a comment

Choose a reason for hiding this comment

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

Thanks!

@@ -0,0 +1,5 @@
---
Copy link

Choose a reason for hiding this comment

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

Curious if you need a changeset for a functionality neutral refactor

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think changesets with [internal] get removed. But you are correct we don't need it here.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 we can prob do without a changeset for internal changes

Copy link
Contributor

Choose a reason for hiding this comment

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

No. You do need a changeset because if vscode-extension depends on this and it doesn't get a bump, then you'll have in-prod-only errors. We should always have a changeset for changes to exports. Even if only used internally.

Copy link
Contributor

@charlespwd charlespwd Jan 15, 2025

Choose a reason for hiding this comment

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

It's less relevant for vscode-extension, but I want to make this clear:

Think of this situation:

  • theme-check is version 1.0.0
  • theme-language-server is version 2.0.0
  • theme-check has a new export but doesn't get a changeset
  • theme-language-server uses that export, creates a changeset
  • next time we publish
    • theme-check-common stays at 1.0.0. 1.0.0 does NOT have the new export!
    • theme-language-server becomes 2.1.0, depends on 1.0.0
  • Works fine locally because you use code from the folder
  • Folks that download theme-language-server from npm get 2.1.0 and 1.0.0
  • 1.0.0 doesn't have the export
  • Uh oh! Breaks in prod.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for the info @charlespwd!

const executables = stdout
.replace(/\r/g, '')
.split('\n')
.filter((exe) => exe.endsWith('bat'));
Copy link
Contributor

@jamesmengo jamesmengo Jan 15, 2025

Choose a reason for hiding this comment

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

For my own learning: When do we encounter a bat? How did you you test this on windows / know what cases to cover?

Copy link
Contributor

Choose a reason for hiding this comment

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

.bat is the .sh of Windows. Most scripts are shipped as .bat on windows and IIRC the where.exe thing will give you a couple of results and you usually want the .bat one.

const shopifyCliPathPromise = getShopifyCliPath();

async function getShopifyCliPath() {
if (isWin) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this worth testing?

Copy link
Contributor

@jamesmengo jamesmengo left a comment

Choose a reason for hiding this comment

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

I see that this is just an extraction - left some non-blocking questions

TIL win32 applies to 64bit as well

Copy link
Contributor

jamesmengo commented Jan 15, 2025

Should we cut a ticket to add error handling in the future? Maybe a notification in the client?

This happens if not auth'ed into CLI.

image.png

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants