Solución: The method 'getInvocation' isn't defined for the type 'DartObjectImpl'

build_runner está fallando al compilar su propio script de build, no tu código. source_gen 3.1.0 y 4.0.0 llaman a DartObjectImpl.getInvocation(), que analyzer 8.4.0 eliminó, y ambos paquetes declaran restricciones lo bastante laxas como para que pub los empareje. Corrígelo actualizando el generador de código de tu pubspec.yaml que fija source_gen por debajo de 4.0.1. Si hoy no puedes actualizar, agrega dependency_overrides: analyzer: 8.3.0 como medida provisional.

El error, completo

Ejecutas dart run build_runner build (o flutter pub run build_runner build) y obtienes un error de compilación del front-end de Dart que apunta a tu caché de pub:

[INFO] Generating build script...
../../.pub-cache/hosted/pub.dev/source_gen-3.1.0/lib/src/constants/revive.dart:82:40:
Error: The method 'getInvocation' isn't defined for the type 'DartObjectImpl'.
 - 'DartObjectImpl' is from 'package:analyzer/src/dart/constant/value.dart'
   ('../../.pub-cache/hosted/pub.dev/analyzer-8.4.1/lib/src/dart/constant/value.dart').
Try correcting the name to the name of an existing method, or defining a method
named 'getInvocation'.
  final i = (object as DartObjectImpl).getInvocation();
                                       ^^^^^^^^^^^^^
[SEVERE] Failed to compile build script. Check builder definitions and generated
script .dart_tool/build/entrypoint/build.dart.

Dos detalles de esa salida hacen el diagnóstico por ti. El archivo que falla está en source_gen, no en tu proyecto. Y los números de versión de esas dos rutas de caché son el bug entero: source_gen-3.1.0 contra analyzer-8.4.1.

Todo lo que sigue se verificó contra los archivos de paquete de pub.dev y aplica a Flutter 3.47.0 con Dart 3.13.0, el canal estable a agosto de 2026, así como a cualquier proyecto Dart 3.x más antiguo que resuelva el mismo par.

Por qué analyzer 8.4.0 eliminó el método

source_gen tiene que responder una pregunta por cada anotación que ve: dado un objeto const que el analyzer ya evaluó, qué código fuente lo recrearía. Eso es lo que hace reviveInstance en source_gen/lib/src/constants/revive.dart, y es la forma en que @JsonSerializable(fieldRename: FieldRename.snake) se convierte en configuración utilizable dentro de un builder.

Para lograrlo, source_gen necesitaba el constructor y los valores de los argumentos detrás de un DartObject. Durante años la única manera de obtenerlos era un import de implementación:

// source_gen 3.1.0, lib/src/constants/revive.dart
// ignore: implementation_imports
import 'package:analyzer/src/dart/constant/value.dart' show DartObjectImpl;

// ...
final i = (object as DartObjectImpl).getInvocation();

Ese comentario // ignore: implementation_imports es el propio lint del analyzer diciéndole a source_gen que está metiendo la mano en un directorio src/ que no ofrece ninguna promesa de estabilidad de API.

El equipo del analyzer cerró la brecha de fondo. La versión 8.1.0, publicada el 2025-08-07, agregó DartObject.constructorInvocation a la superficie pública de package:analyzer/dart/constant/value.dart, devolviendo un ConstructorInvocation con constructor, positionalArguments y namedArguments. En 8.3.0 el punto de entrada anterior seguía presente y marcado para eliminación:

// analyzer 8.3.0, lib/src/dart/constant/value.dart
@Deprecated('Use constructorInvocation instead')
ConstructorInvocationImpl? getInvocation() {
  return constructorInvocation;
}

Analyzer 8.4.0, publicada el 2025-10-15, quitó ese método. constructorInvocation sigue ahí, pero ya no existe nada llamado getInvocation en ninguna parte del paquete. Cualquier código que todavía lo llame deja de compilar en el momento en que esa versión se resuelve.

source_gen ya se había movido. La versión 4.0.1, publicada el 2025-09-04, cambió al getter público y ajustó su propia restricción a analyzer: ^8.1.1:

// source_gen 4.0.1 and later, lib/src/constants/revive.dart
final i = object.constructorInvocation;
if (i != null) {
  url = Uri.parse(urlOfElement(i.constructor.enclosingElement));
  // ...
}

Fíjate en el import de implementación ausente. Esa es la corrección real, y por eso toda versión de source_gen a partir de 4.0.1 es inmune.

El hueco del resolutor que empareja las versiones rotas

Si source_gen 4.0.1 arregló esto en septiembre y analyzer 8.4.0 llegó en octubre, por qué le pasa a alguien. Porque las versiones rotas nunca declararon la incompatibilidad, y pub solo lee declaraciones.

Estas son las restricciones que importan:

source_gen 3.1.0 y 4.0.0 son las dos únicas versiones publicadas que llaman al método eliminado y a la vez permiten analyzer 8.4.x. Su límite superior de <9.0.0 fue una apuesta a que un salto mayor cargaría con cualquier cambio incompatible. El equipo del analyzer eliminó un miembro obsoleto en una versión menor, algo normal para algo que nunca fue API pública en primer lugar.

Pub prefiere la versión más nueva que satisfaga todas las restricciones, así que un proyecto sin otra presión resuelve source_gen 4.3.0 y nunca ve esto. La falla necesita que algo en tu grafo retenga a source_gen. Ese algo casi siempre es un generador de código con un pin de caret. objectbox_generator 5.0.0, publicado el 2025-10-01, declaraba source_gen: ^3.1.0, que resuelve a exactamente una versión, 3.1.0, porque 3.1.0 es la última publicación de la línea 3.x. Dos semanas después llegó analyzer 8.4.0, y todo proyecto con ObjectBox que ejecutó dart pub upgrade obtuvo un script de build que no compilaba.

El changelog de ObjectBox para 5.0.1 nombra la falla directamente: “Generator: migrate to analyzer 8 APIs. Require at least analyzer 8.1.1 and source_gen 4.0.1. Resolves Error: The method 'getInvocation' isn't defined when running the generator using analyzer 8.4.0”.

ObjectBox no estuvo solo. json_serializable 6.11.0 salió con source_gen: ^3.1.0 y lo amplió a >=3.1.0 <5.0.0 en 6.11.1. retrofit_generator 10.0.2, chopper_generator 8.3.1, built_value_generator 8.11.1 y envied_generator 1.2.1 llevaban todos el mismo tipo de pin en la misma ventana. Como source_gen es un único nodo compartido del grafo de dependencias, un generador desactualizado arrastra consigo a todos los demás generadores de tu proyecto hasta 3.1.0. Un proyecto que use freezed, json_serializable y un builder sin mantenimiento culpará al paquete equivocado siempre.

Reproducirlo desde un pubspec limpio

# pubspec.yaml
# Dart 3.9.x. Any SDK that admits analyzer 8.4.x reproduces this.
name: repro
environment:
  sdk: ^3.9.0

dependencies:
  objectbox: 5.0.0

dev_dependencies:
  build_runner: ^2.9.0
  objectbox_generator: 5.0.0

Ejecuta dart pub get y luego lee lo que realmente se eligió:

dart pub deps --style=compact | grep -E 'source_gen|analyzer'

Verás source_gen 3.1.0 y analyzer 8.4.1. Ese par es el bug. dart run build_runner build falla entonces con el error del inicio de este artículo, antes de que se analice una sola línea de tu código.

Solución 1: actualiza el generador que fija source_gen

Esta es la corrección correcta y suele ser de una línea. Encuentra la restricción que está limitando a source_gen y súbela.

Pídele a pub que identifique al culpable exigiendo una versión que no puede darte:

dart pub add dev:source_gen:^4.0.1

La resolución de versiones falla, y la explicación nombra al paquete que sostiene el pin:

Because objectbox_generator 5.0.0 depends on source_gen ^3.1.0 and no versions
        of objectbox_generator match >5.0.0 <6.0.0, objectbox_generator 5.0.0
        requires source_gen ^3.1.0.
So, because repro depends on both objectbox_generator 5.0.0 and
source_gen ^4.0.1, version solving failed.

Lee eso de abajo hacia arriba, igual que leerías cualquier fallo de resolución de versiones de pub. La línea superior es el hecho que tienes que cambiar.

Después sube el paquete nombrado y deja que la corrección fluya:

dart pub upgrade objectbox objectbox_generator
dart run build_runner build --delete-conflicting-outputs

Pisos conocidos como buenos, si prefieres fijarlos explícitamente:

• objectbox_generator 5.0.1 o posterior
• json_serializable 6.11.1 o posterior
• chopper_generator 8.5.0 o posterior
• envied_generator 1.3.2 o posterior
• retrofit_generator 10.2.3 o posterior
• built_value_generator 8.11.2 o posterior

No agregues source_gen a tus propias dev_dependencies como solución. Es una dependencia transitiva de tus generadores, y fijarla en tu pubspec solo mueve el conflicto a tu archivo, donde se va a pudrir.

Solución 2: fija analyzer como medida provisional

Si el generador problemático está abandonado o estás a mitad de una entrega y no puedes tomar una actualización, retén el analyzer en la última versión que aún incluye el método obsoleto:

# pubspec.yaml
# Temporary. Delete once the generator is upgraded.
dependency_overrides:
  analyzer: 8.3.0

Analyzer 8.3.0 (2025-10-10) es la última publicación con getInvocation presente. Esto funciona porque el método obsoleto era un reenvío de una línea a constructorInvocation, así que el comportamiento es idéntico.

Dos costos, ambos reales. dependency_overrides silencia al resolutor para cada paquete del grafo, así que un segundo paquete que realmente necesite analyzer 8.4+ ahora fallará en tiempo de compilación en lugar de en pub get. Y los overrides se ignoran cuando tu paquete se consume como dependencia, así que un paquete publicado no puede enviar esto como corrección para sus propios usuarios. Trátalo como un desbloqueo a nivel de rama con un TODO fechado, y acompáñalo de un job de CI que compile sin el override para enterarte de cuándo deja de hacer falta. Si mantienes más de una rama sobre SDK distintos, apuntar a varias versiones de Flutter desde un solo pipeline de CI es el patrón para mantener ambas honestas.

Solución 3: si la llamada está en tu propio builder

Si la ruta que falla en el error es tu propio paquete y no source_gen, tú escribiste la llamada y la migración es tuya. Es un intercambio directo:

// Before. Requires the implementation import of DartObjectImpl.
// ignore: implementation_imports
import 'package:analyzer/src/dart/constant/value.dart' show DartObjectImpl;

final invocation = (object as DartObjectImpl).getInvocation();

// After. analyzer 8.1.0 and later. Public API, no src/ import.
import 'package:analyzer/dart/constant/value.dart';

final invocation = object.constructorInvocation;
if (invocation != null) {
  final ctor = invocation.constructor;
  final positional = invocation.positionalArguments;
  final named = invocation.namedArguments;
}

Borra el ignore de implementation_imports junto con ella. Después fija tu propio piso en analyzer: '>=8.1.1' para que pub no pueda entregarle a tu código un analyzer sin el getter. Ese límite inferior es la parte que la gente se salta, y es lo que convierte un paquete corregido de nuevo en uno roto para alguien sobre un SDK más antiguo.

Ya que estás ahí, ten en cuenta que ConstructorInvocation.constructor2 existe y está obsoleto en favor de constructor. Migra ambos en la misma pasada en lugar de cambiar una eliminación por la siguiente.

Trampas y falsos parecidos

flutter clean no soluciona esto y nunca lo hizo. El consejo más repetido para fallos de build_runner es borrar .dart_tool y volver a compilar. Aquí eso solo reejecuta la misma compilación contra las mismas versiones resueltas. Si el error menciona un archivo dentro de .pub-cache, la resolución está mal y ninguna limpieza de caché la cambia.

--delete-conflicting-outputs tampoco lo soluciona. Ese flag atiende una compilación que produjo un archivo que otro builder quiere escribir. Se ejecuta después de que el script de build compila, y aquí el script de build nunca compila.

El lockfile es el disparador habitual. Nada de tu pubspec cambió; un dart pub upgrade, un checkout limpio de CI sin pubspec.lock commiteado, o el pub get de un compañero movió el analyzer a 8.4.x mientras source_gen se quedó fijado en 3.1.0. Si la máquina de un colega todavía compila, compara los dos lockfiles antes que nada.

Errores hermanos, causa idéntica. The getter 'name' isn't defined for the class 'NamedType', The getter 'tmp' isn't defined for the class 'Diagnostic' y DotShorthandConstructorInvocation isn't defined son todos el mismo modo de fallo: un builder compilado contra una API del analyzer que se movió. El diagnóstico no cambia. Lee las dos versiones en las rutas de caché del error, encuentra el paquete que fija la más vieja, actualízalo. Es el mismo tipo de ruptura que un plugin que elimina su constructor sin nombre, salvo que la API pertenece a un paquete que nunca escribiste.

Analyzer 9.0.0 no es el límite que quieres. Salió el 2025-10-23, ocho días después de 8.4.0. Poner analyzer: <9.0.0 no te protege, porque 8.4.x ya está por debajo. Los únicos pisos seguros son source_gen: '>=4.0.1' del lado del generador y analyzer: '>=8.1.1' del tuyo.

Relacionados

• Leer la prueba de fallo de pub es la habilidad central aquí: Version solving failed in pubspec.yaml recorre la salida de PubGrub línea por línea.
• freezed es un builder de source_gen como cualquier otro, así que esta falla puede golpear a un proyecto que solo lo usa para clases de datos. Dart records vs clases Freezed cubre cuándo necesitas la generación de código en absoluto.
• El generador de Riverpod se apoya en la misma pila: migrar de Riverpod 2.x a Riverpod 3.0 incluye el salto de codegen.
• Una actualización de paquete que elimina un constructor en vez de un método: The class ‘GoogleSignIn’ doesn’t have an unnamed constructor.
• Para mantener un proyecto compilando mientras aterriza una actualización de generador, mira apuntar a varias versiones de Flutter desde un solo pipeline de CI.

Fuentes

• Changelog de source_gen, por el paso de 4.0.1 a analyzer: ^8.1.1. Las restricciones de versión y las fechas de publicación se leyeron de los archivos de paquete de pub.dev de 3.1.0, 4.0.0 y 4.0.1.
• Changelog de analyzer, por 8.1.0 agregando DartObject.constructorInvocation. La presencia del getInvocation() obsoleto en 8.3.0 y su ausencia en 8.4.0 se confirmaron contra los archivos publicados de ambas versiones.
• Changelog de objectbox, versión 5.0.1, publicada el 2025-10-29, que nombra este error exacto y su corrección.
• build_runner en pub.dev. El mensaje “Failed to compile build script” viene de lib/src/bootstrap/bootstrapper.dart.
• dart pub deps y la documentación del resolutor PubGrub para los comandos de diagnóstico.