## TL;DR

dbt looks for generate_alias_name to override default alias naming, and in newer versions also calls it internally in more paths. If a custom macro by that name was deleted, misnamed, or lives outside macro paths, compilation fails. Restore a correct generate_alias_name macro in macros/ (or remove the stale reference) and parse again.

```text
Compilation Error: macro 'generate_alias_name' not found in any package
```

## Use this when

- dbt compile fails with Compilation Error macro generate_alias_name not found in any package
- you deleted, renamed, or moved a custom generate_alias_name macro
- the error appeared after a dbt upgrade or after cleaning up the macros folder

## Not for this skill when

- you never customized alias naming and the error names a different macro, search for that macro instead
- aliases are wrong but compilation succeeds, that is a logic issue inside an existing generate_alias_name
- the macro exists in a package you removed from packages.yml, restore the package if you still depend on it

## Steps

1. Search the whole project, including dbt_packages, for macro generate_alias_name definitions and for the file that used to hold yours in version control history.
   Verify: you know whether a definition exists anywhere and where it went.

2. If it was deleted by accident, restore it under macros/ with the standard signature generate_alias_name(custom_alias_name, node) returning custom_alias_name if provided, else node.name, preserving any project tweaks such as trimming prefixes.
   Verify: a generate_alias_name macro exists in a macro path with the two-argument signature.

3. If you intentionally removed customization, make sure nothing else references the custom behavior, and confirm your dbt version ships its default: test by adding the standard default implementation rather than leaving none, on versions that require the macro to resolve.
   Verify: dbt parse completes with no macro lookup error.

4. Compile models that use custom aliases (alias config in YAML) and check the compiled relation names.
   Verify: compiled SQL uses the expected alias names for aliased models.

## Variant phrasings

### macro exists but error persists
Check macro-paths in dbt_project.yml: a macros folder outside the configured paths is invisible. Also check for a typo in the macro name inside the file.

### error only in dbt Cloud
Cloud may run a different dbt version than local. Align versions; macro resolution for alias generation changed across 1.x releases.

Compatibility: dbt-core 1.x alias generation; signature generate_alias_name(custom_alias_name, node). Applies on all adapters wherever custom aliases are used.

## Why it happens

Alias generation is not a hardcoded fallback in every code path: dbt dispatches through a macro named generate_alias_name so projects can override naming. If that macro cannot be resolved in the project or any installed package, any model needing an alias fails compilation, even models that never customized anything.

## Edge cases / pitfalls

- Overrides that ignore node.version or late-binding details can misname versioned models; keep the default logic and add tweaks narrowly.
- Two generate_alias_name definitions recreate the duplicate macro error; keep exactly one project definition.
- Renaming the file is harmless, renaming the macro inside it is not; the lookup is by macro name, not file name.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fS2Pkej70h2UyakRZES8nQ