Auto-detect and linkify URLs in plain-string TokenizedText items by ryancbahan · Pull Request #7384 · Shopify/cli

ryancbahan · 2026-04-23T21:32:06Z

WHY are these changes introduced?

Long URLs embedded as plain strings in CLI error messages wrap across multiple lines inside the fixed-width error banner (~53 chars on an 80-col terminal). The wrap splits the URL with the border's │ characters, producing output that is neither clickable nor copy-pasteable as a single URL.

WHAT is this pull request doing?

Three small changes in packages/cli-kit:

TokenizedText.tsx — New renderStringWithLinks helper auto-detects http(s)://… URLs in plain-string tokens, strips common trailing sentence punctuation, and routes each URL through the existing <Link> component. This is the chokepoint through which all banner/alert bodies render, so server-returned error strings benefit automatically.
FatalError.tsx — The error.message fallback (used when a FatalError is constructed with a plain OutputMessage instead of a TokenItem) now flows through TokenizedText instead of a bare <Text>, picking up the same URL treatment.
Link.tsx — Two fixes to the non-OSC-8 fallback path, both limited to behavior inside a LinksContext (i.e. inside a Banner):
- When a link has no label, render just [N] as the in-body anchor instead of url [N] (prevents the URL from being visible in-body where it would wrap).
- Always use the footnote mechanism when a LinksContext is present, regardless of whether a label was provided (previously the method short-circuited for label-less links and emitted the raw URL inline).

Net effect

Before:

│ See specification requirements: https://shopify.dev/docs/apps/build/sales- │
│ channels/channel-config-extension#specification-properties                 │

After:

│ See specification requirements: [1]                                        │
╰────────────────────────────────────────────────────────────────────────────╯
[1] https://shopify.dev/docs/apps/build/sales-channels/channel-config-extension#specification-properties

On OSC 8 terminals (iTerm2, modern Terminal.app, VS Code, Warp, Kitty, WezTerm, Ghostty) the [1] anchor is a clickable hyperlink to the full URL. On terminals without OSC 8 support, the URL appears outside the bordered box in the footnote block, where it can still wrap at terminal width but is not interleaved with │ characters, so copy-paste recovers the full URL.

How to test your changes?

Unit coverage added

TokenizedText.test.tsx: 5 tests — no-URL passthrough, URL preserved without OSC 8, URL wrapped in OSC 8 when supported, multiple URLs, trailing punctuation stripped.
Alert.test.tsx and FatalError.test.tsx: inline snapshot integration tests that render a long-URL message inside a real Banner / FatalError and lock in the [1] in-body + URL-in-footnote layout.

Visual QA in a real terminal

pnpm --filter @shopify/cli-kit build
Create a small script that calls renderError / renderFatalError with a plain-string body containing a long URL, then run it with node.
Verify the URL is no longer interleaved with │, the [1] anchor is clickable (OSC 8 terminals), and copy-pasting the footnote URL yields a single clean URL.
Force the non-OSC-8 path with FORCE_HYPERLINK=0 and confirm the [N] + footnote layout still renders cleanly.

Post-release steps

None.

Checklist

I've considered possible cross-platform impacts (Mac, Linux, Windows) — change is pure text rendering; OSC 8 detection is delegated to the existing supports-hyperlinks dependency.
I've considered possible documentation changes — none needed; the fix is transparent to callers.
I've considered analytics changes to measure impact — not applicable.
The change is user-facing — added a patch changeset (bug fix).

ryancbahan · 2026-04-23T21:32:20Z

Auto-detect and linkify URLs in plain-string TokenizedText items #7384 👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

isaacroldan

Review assisted by pair-review

isaacroldan · 2026-04-24T08:50:39Z

 * links, and commands.
 */
+const URL_REGEX = /https?:\/\/\S+/g
+const URL_TRAILING_PUNCTUATION = /[.,;:!?)\]}>'"]+$/


🐛 Bug: URL_TRAILING_PUNCTUATION = /[.,;:!?)\]}>'"]+$/ unconditionally strips ), ], }, and > from the end of a matched URL, but these characters are legal URL suffixes. Real-world examples that would break: Wikipedia disambiguation links like https://en.wikipedia.org/wiki/Ruby_(programming_language), MDN Function() pages, Microsoft Learn URLs using parens in paths, and query strings ending in JSON-array-style values. Because this helper is now the chokepoint for every plain string passed through TokenizedText, any such URL in a server-returned error message will have its closing bracket stripped, and the <Link> component will emit an OSC 8 escape pointing at a broken target (with the trailing ) rendered outside the link). None of the new tests exercise URLs containing (), so this silent corruption is uncovered.

Suggestion: Narrow the character class to unambiguous sentence punctuation, or balance-count parens before stripping. Minimal fix:

Suggested change

const URL_TRAILING_PUNCTUATION = /[.,;:!?)\]}>'"]+$/

const URL_TRAILING_PUNCTUATION = /[.,;:!?'"]+$/

And add a test for https://en.wikipedia.org/wiki/Foo_(bar) to lock the behavior in.

isaacroldan · 2026-04-24T08:50:40Z

 const TokenizedText: FunctionComponent<TokenizedTextProps> = ({item}) => {
  if (typeof item === 'string') {
-    return <Text>{item}</Text>
+    return renderStringWithLinks(item)


📐 Design: The PR is framed as a Banner/alert fix, but renderStringWithLinks runs on every plain-string token passing through TokenizedText. That includes Alert, FatalError, List, TabularData, DangerousConfirmationPrompt, Prompts/PromptLayout, Prompts/InfoMessage, and TextPrompt. In non-Banner contexts there's no LinksContext, so the Link component falls back to raw-URL output for non-OSC-8 terminals (preserved) but emits OSC 8 escapes on OSC-8-capable terminals (behavior change). A concrete example: the placeholder URL in packages/app/src/cli/services/dev/urls.ts:86 (Valid format: "https://my-tunnel-url:port") will now be rendered as a clickable escape to a non-existent host. Reviewers of downstream packages won't catch this from the PR description alone.

Suggestion: Either (a) scope the auto-detection to contexts that own a LinksContext by threading an explicit flag through (e.g. an autoLinkify prop or opt-in from Banner/Alert/FatalError), or (b) keep the current broad behavior but update the PR description/changeset and add snapshot coverage for non-Banner callers (TabularData, List, prompts) so the behavior change is visible at review time.

I tested this and does indeed break other alerts:

You can trigger this one by running:

pnpm shopify app dev --tunnel-url https://wrong

johnnie-chen · 2026-04-24T15:30:12Z

+      expect(lastFrame()).toContain(`]8;;${url}${url}]8;;`)
+    })
+
+    test('detects multiple URLs in the same string', async () => {


Might be worth adding edge test cases where there's back to back URLs

Catherine-Fu · 2026-04-27T16:35:24Z

 * `TokenizedText` renders a text string with tokens that can be either strings,
 * links, and commands.
 */
+const URL_REGEX = /https?:\/\/\S+/g


Are there any existing libraries we can use to validate URLs?

we're actively trying to reduce lib usage given the amount of supply chain attacks.

- Narrow URL_TRAILING_PUNCTUATION so legal URL chars `)`, `]`, `}`, `>` are no longer stripped (Wikipedia/MDN/Microsoft Learn URLs). - Gate renderStringWithLinks on a non-null LinksContext so non-Banner consumers (TabularData, prompts, InfoMessage) keep their original rendering unchanged. - Validate detected URLs via the WHATWG URL constructor and require the hostname to contain a dot. Rejects user typos and placeholder strings like https://asda and https://my-tunnel-url:port that should not appear as clickable hyperlinks (the case Isaac screenshotted). Tests: - TokenizedText: parens-in-URL, back-to-back URLs, no-context passthrough, no-dot hostname, non-numeric port. - Link: label-less `[N]` rendering and always-footnote registration inside a LinksContext. - FatalError: snapshot reproducing the AbortError tunnel-url case so the regression is locked in. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

- isLikelyRealUrl now narrows to TypeError (URL constructor's failure type) and rethrows anything else (no-catch-all/no-catch-all). - Reformat WithLinksContext prop type onto multiple lines (prettier). - Drop unnecessary backslash escapes from a template-literal inline snapshot in FatalError.test.tsx (no-useless-escape). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

github-actions · 2026-04-28T15:30:03Z

Differences in type declarations

We detected differences in the type declarations generated by Typescript for this branch compared to the baseline ('main' branch). Please, review them to ensure they are backward-compatible. Here are some important things to keep in mind:

Some seemingly private modules might be re-exported through public modules.
If the branch is behind main you might see odd diffs, rebase main into this branch.

New type declarations

We found no new type declarations in this PR

Existing type declarations

packages/cli-kit/dist/private/node/ui/components/TokenizedText.d.ts

@@ -40,9 +40,5 @@ export declare function appendToTokenItem(token: TokenItem, suffix: string): Tok
 interface TokenizedTextProps {
     item: TokenItem;
 }
-/**
- *  renders a text string with tokens that can be either strings,
- * links, and commands.
- */
 declare const TokenizedText: FunctionComponent<TokenizedTextProps>;
 export { TokenizedText };
\ No newline at end of file

Catherine-Fu

The expected behaviour is that the link in CLI validation messages should be easily clickable or copyable as a complete, valid URL.

I don’t have much context on the CLI library, so I’d prefer to have another reviewer take a look and approve this.

graphite-app · 2026-05-06T11:23:06Z

Merge activity

May 6, 11:23 AM UTC: This pull request can not be added to the Graphite merge queue. Please try rebasing and resubmitting to merge when ready.
May 6, 11:23 AM UTC: Graphite disabled "merge when ready" on this PR due to: a merge conflict with the target branch; resolve the conflict and try again..

github-actions · 2026-06-06T04:49:46Z

This PR 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.

preserve link strings

e1c0f61

ryancbahan changed the title ~~preserve link strings~~ Auto-detect and linkify URLs in plain-string TokenizedText items Apr 23, 2026

ryancbahan marked this pull request as ready for review April 23, 2026 21:36

ryancbahan requested a review from a team as a code owner April 23, 2026 21:36

isaacroldan reviewed Apr 24, 2026

View reviewed changes

johnnie-chen reviewed Apr 24, 2026

View reviewed changes

Catherine-Fu reviewed Apr 27, 2026

View reviewed changes

Comment thread packages/cli-kit/src/private/node/ui/components/Link.tsx

Catherine-Fu reviewed Apr 27, 2026

View reviewed changes

github-actions Bot added the Area: @shopify/cli @shopify/cli package issues label Apr 28, 2026

isaacroldan mentioned this pull request Apr 28, 2026

Fix label-pr workflow checking out merge ref instead of PR head #7420

Merged

2 tasks

ryancbahan requested review from Catherine-Fu, isaacroldan and johnnie-chen April 28, 2026 15:50

Catherine-Fu approved these changes Apr 28, 2026

View reviewed changes

shopify-river Bot mentioned this pull request May 4, 2026

Opt-in CommonMark link parsing in Banner-rendered plain strings #7458

Merged

4 tasks

github-actions Bot added the no-pr-activity label Jun 6, 2026

github-actions Bot closed this Jun 13, 2026

	const URL_TRAILING_PUNCTUATION = /[.,;:!?)\]}>'"]+$/
	const URL_TRAILING_PUNCTUATION = /[.,;:!?'"]+$/

Uh oh!

Conversation

ryancbahan commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

WHY are these changes introduced?

WHAT is this pull request doing?

How to test your changes?

Post-release steps

Checklist

Uh oh!

ryancbahan commented Apr 23, 2026

Uh oh!

isaacroldan left a comment

Choose a reason for hiding this comment

Uh oh!

isaacroldan Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

johnnie-chen Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

isaacroldan Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

isaacroldan Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

isaacroldan Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

johnnie-chen Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Catherine-Fu Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

ryancbahan Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Apr 28, 2026

Differences in type declarations

New type declarations

Existing type declarations

Uh oh!

Catherine-Fu left a comment

Choose a reason for hiding this comment

Uh oh!

graphite-app Bot commented May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merge activity

Uh oh!

github-actions Bot commented Jun 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ryancbahan commented Apr 23, 2026 •

edited

Loading

isaacroldan Apr 24, 2026 •

edited

Loading

graphite-app Bot commented May 6, 2026 •

edited

Loading