refactor: remove unnecessary prop from links

[essenmitsosse]

In #1240 @alexdln fixed two regressions I had introduce in #1071:

1. a regression with the icon size in links (for some versions on the package page)
2. a regression with the truncation of long version names

Unfortunatly that did two things:

• by fixing 1.: introduce a new prop for the icon size, that would manually be set when changing the font size of a link (which would still make it easy to use the component and end up with a broken design)
• by fixing 2.: added an explicit margin to all icons in links, which broke icon only links
  

This fixes this by:

• making the icon size relative to the font size of a link/button, no matter how the font size was set. This makes the components more robust and easier to use while ensuring a consistent design. This might still be insufficient in some cases, but not in any we currently have. The result should be identical to the fix @alexdln introduced
• refactor the links in /Package/Versions so that truncate works, but the links can keep their flex layout

To avoid flex! on links it additionally:

• adds a new link-block variant, to properly let a link be a block element, as well as changing all buttons and links with button design to be blocks by default (couldn't find any case where this would be a problem)

It also fixes a very rare case were the tag name would be truncated without need.

@alexdln thanks for spotting the regression! Would you be so kind and double check, I didn't make things worse again and missed anything?

Preview:

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
npmx.dev	Ready	Preview, Comment	Feb 9, 2026 1:48am

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
docs.npmx.dev	Ignored	Preview	Feb 9, 2026 1:48am
npmx-lunaria	Ignored		Feb 9, 2026 1:48am

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a block?: boolean prop to Button/Base.vue and Link/Base.vue, removes the iconSize prop and related ICON_SIZE_MAP logic from Link/Base.vue, and replaces size-dependent icon classes with a fixed size-[1em] class in Button, Link and Tag components. Button and Link root classes now switch between inline-flex and flex based on the new block prop; Link sizing logic was refactored to be block-aware (isButton, isButtonSmall/Medium). Multiple component usages were updated to pass block or remove inline-flex classes; no other public API changes beyond the added/removed props.

Possibly related PRs

• feat: extract button and link component, unify and improve design #1071: Modifies the same Button/Base.vue and Link/Base.vue components (props and icon/class handling).
• fix: restore rows truncates in package page #1240: Adjusts Link/Base.vue icon sizing and layout props, including block-related changes.
• fix: align deprecated version icon and text #1125: Changes Package/Versions.vue link/layout classes in ways that overlap with this PR's block/inline-flex updates.

Suggested labels

front

Suggested reviewers

• danielroe

🚥 Pre-merge checks | ✅ 1

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description check	✅ Passed	The pull request description clearly relates to the changeset, explaining the rationale for adding a block prop to buttons and links, fixing icon sizing issues, and addressing regressions from previous changes.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

No actionable comments were generated in the recent review. 🎉

🧹 Recent nitpick comments

app/components/Link/Base.vue (1)

56-57: Consider using isButton.value for consistency.

isButtonSmall and isButtonMedium duplicate the !isLink.value check rather than reusing isButton.value. While functionally equivalent, using isButton.value would be more maintainable if the button detection logic ever changes.

♻️ Suggested refactor

-const isButtonSmall = computed(() => props.size === 'small' && !isLink.value)
-const isButtonMedium = computed(() => props.size === 'medium' && !isLink.value)
+const isButtonSmall = computed(() => props.size === 'small' && isButton.value)
+const isButtonMedium = computed(() => props.size === 'medium' && isButton.value)

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

app/components/Package/Versions.vue (1)

370-370: Consider using colon-syntax for the UnoCSS icon.

The icon class i-carbon-warning-hex should use the colon-separated form i-carbon:warning-hex for better UnoCSS resolution performance. This applies to all similar occurrences in this file (lines 423, 525, 601, 662, 715).

♻️ Suggested change

-:classicon="row.primaryVersion.deprecated ? 'i-carbon-warning-hex' : undefined"
+:classicon="row.primaryVersion.deprecated ? 'i-carbon:warning-hex' : undefined"

Based on learnings: "prefer colon-syntax for icons (e.g., i-carbon:checkmark) over the dash-separated form (i-carbon-checkmark). This aids UnoCSS in resolving the correct collection directly."

[alexdln]

Don't mix responsibilities. The prop should be responsible for a specific area

[essenmitsosse]

I know what you mean. This goes back to my previous comment: Adding another prop, that is only relevant for a certain variant is also not the best design. Again: probably best to split the component. Would you be fine with this as an intermediate solution?

[alexdln]

Let's call this inline already and use it for both buttons and links

[alexdln]

Sorry, missed comment

[essenmitsosse]

Yeah I see. Just one thing: Would it default to true for links but false for buttons?

[essenmitsosse]

Ah, just noticed buttons are currently inline as well. Ok I'll have a go on it.

[alexdln]

The point isn't that there are so many options, but that they're for completely different purposes. In your set of conditions below, you can see what you're using for what. Essentially, you're generating several other props from this one

And this list of conditions below is actually more logical for DX, and that's what you came up with. We're more comfortable writing and working with a component when we clearly understand what the result will be

false by default please. It's easier and more common to write just inline, not inline="false"

[alexdln]

This is also pretty standard practice when it's responsible for a narrow section: disabled, autocorrect, checked, hidden, open. It's probably even more standard in Vue, since it's positioned as closer to the HTML

[alexdln]

block is better, yes (but now we've run into a terminology conflict. Would be better to work on that in the next iteration)

[essenmitsosse]

Yeah, never would have liked to set true as the default for the reasons you stated. What terminology conflict do you mean?

[essenmitsosse]

@alexdln Thanks for the input. You were right about the prop being overloaded. I went with having the components be inline (inline-flex by default with the prop block changing them to be block elements (flex).

I would handle the inline-inline links separately and opened an issue for the them (#1252).

Are you fine with this?

[alexdln]

How about putting the rest of the comments there too (or in another issue)?

[alexdln]

Looks good to me, thanks for working on it and polishing it 🩵

[essenmitsosse]

@alexdln I think I got all your comments that are issue worthy. Thanks for the input!

[alexdln]

@essenmitsosse Please update issues descriptions a bit so that newcomers to the project can more easily understand what happened - in case someone will want to take it right away

[alexdln]

@essenmitsosse Also, to rework the props in general. Variant still has too much responsibility.

One for color, one for type (link / button)