Pre-publish checkout-ui-extensions: brought over public packages, re-generated docs

[jamesvidler]

Background

For https://github.com/Shopify/ui-extensions/issues/320.

This PR brings over the latest versions of the checkout-ui-extensions and checkout-ui-extensions-react from the checkout-web repo. A follow-up PR will publish the packages.

In addition, the docs have been re-generated based off the latest package sources.

This has a sibling PR https://github.com/Shopify/shopify-dev/pull/20496 that shows the re-generated documentation that will be shipped to shopify.dev

Solution

Followed the publishing packages instructions.

Notes:

• Manually had to merge the package.json for both packages because they had newer versions of dependancies.
• There is a conflict with using "@quilted/react-testing": "^0.4.10" in the ui-extension repo as it causes errors when running tests. The package causing issues moved to only using export conditions, which jest doesn't support yet. To get around this and not have to manually revert the version, added a resolution for it:
  

  ui-extensions/package.json

  Lines 60 to 65 in 1816206

  	"resolutions": {
  	"@typescript-eslint/eslint-plugin": "^4.0.0",
  	"@typescript-eslint/experimental-utils": "^4.0.0",
  	"@typescript-eslint/parser": "^4.0.0",
  	"typescript": "^4.1.0",
  	"@quilted/react-testing": "^0.3.7"

• Had to manually apply 2 linting fixes
• Removed folder path mapping in exports package.json (Fix instances of deprecated folder mapping within exports in package.json #292)

🎩

Questions for Reviewers

1. There are a lot of changes to yarn.lock that I think have been excluded in past merges, but probably should be updated. Any red flags?

Doc Updates

Review the doc files changed by this PR both in this repo and in https://github.com/Shopify/shopify-dev/pull/20496.

Package Update

It's important to do a smoke test on how this package will function before we publish to NPM. Normally, you would use yarn link to do this, but there's an issue with that right now that causes an invalid react hook error.

1. Clone this patch and run yarn && yarn build.
2. Copy ./packages/checkout-ui-extensions and ./packages/checkout-ui-extensions-react and paste them into the ./node_modules/@shopify folder in your an existing checkout extension, or a newly created one.

Verify that the extension runs using shopify extension serve.

What changes to look for - to confirm you are using the latest package when testing?
There are many changes, but one easy thing to look for is there should no longer be a ButtonGroup component. That has been removed in the latest version.

Checklist

• I have 🎩'd these changes
• I have updated relevant documentation

[jamesvidler]

Ran into an issue tophatting this using a production extension locally:

The actual error message wasn't logged in the console, but this is the error here before it was swallowed up:

"Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://reactjs.org/link/invalid-hook-call for tips about how to debug and fix this problem."

Will dig into this further on Tuesday.

[jamesvidler]

Ran into an issue tophatting this using a production extension locally:

Turns out this was an issue related to using yarn link. Instead, directly copying the files into the node_modules allowed me to successfully tophat this. https://shopify.slack.com/archives/C01FT69928K/p1653403013468999

[lemonmade]

@jffortier do you know what the tuple version of this type means?

[jffortier]

Yes!

• when one value is set, we render the correct HTML element if one exist for that specific role. ex: <View accessibilityRole="header"> will render <header>
• when a second value is set, we then set the role property on the element. ex: <View accessibilityRole={['header', 'banner']}> will render <header role="banner">

It can be useful for many use cases. In Self Serve, they need the list/listItem semantic and the stylistic flexibility of View for their UI. They also needed a list item that had the role of "separator".

<View accessibilityRole="list" {...styleOnlyPossibleWithView}>
   <View accessibilityRole="listItem">...</View>
   <View accessibilityRole={{'listItem', 'separator']} border="base" />
   <View accessibilityRole="listItem">...</View>
</View>

Which renders

<ul>
   <li>...</li>
   <li role="separator" class="css-class-for-border" />
   <li>...</li>
</ul>

[lemonmade]

Hmm, interesting. I think we should probably add some of this content as documentation for the prop, unless a deeper explainer is somewhere else. It wasn't clear to me what they meant, and I still find it a bit hard to understand from this type what values are actually useful to use in the two-value format (e.g., ['listItem', 'listItem'] is valid here but presumably not a thing you'd ever want in practice?)

[jffortier]

I think we should probably add some of this content as documentation for the prop, unless a deeper explainer is somewhere else.

Yeah, I remember providing that feedback in the PR, but now can't find the detailed explanation in the code. Not sure what happened. I'll add one.

I still find it a bit hard to understand from this type what values are actually useful to use in the two-value format (e.g., ['listItem', 'listItem'] is valid here but presumably not a thing you'd ever want in practice?)

We can provide examples in that description. Yes, ['listItem', 'listItem'] is valid with this API. We currently allow it (eg: this will render <li role="listItem">, but could decide to not do anything with the second value when its identical to the first.

[lemonmade]

A bunch of these can technically be deduplicated, I'd probably runnpx yarn-deduplicate with the --packages flag to avoid these new duplicates.

[kumar303]

The actual error message wasn't logged in the console, but this is the error here before it was swallowed up

@marvinhagemeister filed an issue for showing the actual error: https://github.com/Shopify/temp-project-mover-megswim-20250326195306/issues/27

[kumar303]

I didn't tophat but this looks good to me

[marvinhagemeister]

The actual error message wasn't logged in the console, but this is the error here before it was swallowed up

@marvinhagemeister filed an issue for showing the actual error: Shopify/temp-project-mover-megswim-20250326195306#27

Good catch! Looks like there is a deeper issue where error messages get swallowed completely