Vyper 0.4.0: Mandatory @external/@internal Decorators Break Legacy Contracts

Goal

Upgrade a legacy Vyper 0.3.x codebase to 0.4.x while preserving public API compatibility.

Constraints and Uncertainty

In 0.4.0 every function must be annotated with either @external or @internal; the previous implicit public default is no longer accepted. This change can silently alter contract behavior if a function intended to be externally callable is left unannotated, leading to compile failures or unintended visibility. Additionally, the new module system replaces some of the old inheritance‑free patterns, raising questions about how to restructure shared logic.

Unresolved Questions

• What is the most efficient strategy to automatically annotate all functions in a large codebase without risking incorrect visibility?
• How does the removal of implicit visibility affect contracts that rely on default public functions for testing or tooling integrations?
• When migrating shared logic, should teams rewrite legacy patterns as modules or keep them flattened, and what tooling exists to support that decision?