Enable formula-to-cask migrations within the same tap

[Copilot]

Resolves the issue where tap maintainers could not migrate formulae to casks within their own tap using tap_migrations.json.

Problem

Previously, tap_migrations.json only supported formula-to-cask migrations when the target was the homebrew/cask tap. This prevented third-party tap maintainers from migrating their formulae to casks when switching from building from source to distributing precompiled binaries.

For example, GoReleaser maintainers wanted to migrate users from their formula to a cask within the same goreleaser/tap, but there was no way to automatically handle this migration during brew update.

Solution

Extended the migration detection logic in migrate_tap_migration to check if the migration target is a cask by examining the target tap's cask_tokens, in addition to checking if the migration is to homebrew/cask.

# Before
if new_tap_name.start_with?("homebrew/cask")

# After
if new_tap_name.start_with?("homebrew/cask") || new_tap.cask_tokens.include?(new_name)

Usage

Tap maintainers can now add migrations like this to their tap_migrations.json:

{
  "old-formula": "user/tap/new-cask"
}

When users run brew update, the system will:

• Detect that the migration target is a cask
• Automatically unlink the formula and install the cask (if the tap is installed and Caskroom exists)
• Or provide clear instructions for manual migration

Benefits

• ✅ Backward compatible: All existing migrations continue to work unchanged
• ✅ Minimal change: Only one line of logic modified
• ✅ Safe: No false positives - only detects actual casks in installed taps
• ✅ Universal: Benefits all third-party taps, not just core taps

Testing

• All existing tests pass
• New test case added to verify same-tap formula-to-cask migration detection
• Typecheck and style checks pass

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Tap migrations should allow to migrate from formula to cask in the same tap</issue_title>
<issue_description>### Verification

• This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature

The current tap_migrations.json file allows people to define migrations in or outside a tap. But a scenario where the maintainer starts to distribute prebuild binaries rather than building in a formula is not covered. Therefore it would be useful if tap_migrations.json would also check if the migration is from a formula to a cask and act accordingly.

What is the motivation for the feature?

GoReleaser is now distributing precompiled binaries for brew as casks rather than formulae. But this leaves a lot of users with a formula and a cask with the same name in the same tap, and no way to automatically switch the users.

See: https://github.com/orgs/goreleaser/discussions/5563#discussioncomment-14180870

How will the feature be relevant to at least 90% of Homebrew users?

A lot of smaller Go projects use Goreleaser and distribute their software to brew that way. Making the migration to casks (that better fit the Homebrew model) easier should be better for all Homebrew users.

What alternatives to the feature have been considered?

Just hoping users notice the disabling of the formulae and manually switch to casks.</issue_description>

Comments on the Issue (you are @copilot in this section)

@MikeMcQuaid > Therefore it would be useful if `tap_migrations.json` would also check if the migration is from a formula to a cask and act accordingly.

This is already possible: https://github.com/Homebrew/homebrew-core/blob/b83323dad1849149ebc425b22d95322b66e23360/tap_migrations.json#L31-L32

The actual migration itself happens as part of brew update so that's the code that needs to change here.</comment_new>
<comment_new>@SMillerDev
Yeah, I guess the important part is here:

But this leaves a lot of users with a formula and a cask with the same name in the same tap

I'm planning to have a look to see if I can find it in brew upgrade.</comment_new>
<comment_new>@MikeMcQuaid

I'm planning to have a look to see if I can find it in brew upgrade.

@SMillerDev brew update.

Here's the relevant logic that'd need extended to handle all taps:

brew/Library/Homebrew/cmd/update-report.rb

Lines 664 to 688 in df73746

	new_tap = Tap.fetch(new_tap_name)
	# For formulae migrated to cask: Auto-install cask or provide install instructions.
	if new_tap_name.start_with?("homebrew/cask")
	if new_tap.installed? && (HOMEBREW_PREFIX/"Caskroom").directory?
	ohai "#{name} has been moved to Homebrew Cask."
	ohai "brew unlink #{name}"
	system HOMEBREW_BREW_FILE, "unlink", name
	ohai "brew cleanup"
	system HOMEBREW_BREW_FILE, "cleanup"
	ohai "brew install --cask #{new_name}"
	system HOMEBREW_BREW_FILE, "install", "--cask", new_name
	ohai <<~EOS
	#{name} has been moved to Homebrew Cask.
	The existing keg has been unlinked.
	Please uninstall the formula when convenient by running:
	brew uninstall --force #{name}
	EOS
	else
	ohai "#{name} has been moved to Homebrew Cask.", <<~EOS
	To uninstall the formula and install the cask, run:
	brew uninstall --force #{name}
	brew tap #{new_tap_name}
	brew install --cask #{new_name}
	EOS
	end

FWIW, I believe what most users are ask is "what should I do so my users can just run brew upgrade and it just work?".

@caarlos0 Thanks! Yes, I think this is the right way about thinking about this problem and what should be solved in this issue 👍🏻 </comment_new>

Fixes #20585

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.