Tanto Embroider como pnpm solicitan que los paquetes declaren sus dependencias correctamente: Enumere una dependencia (si y solo) si se usa.

Esto es difícil de hacer cuando se trabaja en un monorepo grande (considere una aplicación Ember con muchos complementos de Ember y paquetes de Node) que usa Yarn@v1. Los desarrolladores pueden olvidarse de actualizar el package.json, porque la aplicación Ember puede compilarse y ejecutarse incluso cuando falta una dependencia, siempre y cuando se extraiga de otro paquete.

Entonces, ni la compilación ni la ejecución pueden decirnos si algún paquete no declaró correctamente sus dependencias. ¿De qué otra manera podemos arreglar el package.json para que podamos introducir Embroider y pnpm?

1. Análisis de código estático

Dado un archivo, podemos ver qué dependencias deberían estar presentes, porque sabemos cómo funcionan JavaScript y Ember.

Por ejemplo, si se mostrara un archivo JavaScript (o TypeScript),

import { setupIntl } from 'ember-intl/test-support';
import { setupRenderingTest as upstreamSetupRenderingTest } from 'ember-qunit';

export function setupRenderingTest(hooks, options) {
  upstreamSetupRenderingTest(hooks, options);

  // Additional setup for rendering tests can be done here.
  setupIntl(hooks, 'de-de');
}

podemos saber por las declaraciones de importación que el paquete depende de ember-intl y ember-qunit.

Y, si se mostrara un archivo de plantilla,

{{page-title "My App"}}



{{outlet}}

nuestro conocimiento de Ember y su ecosistema de complementos nos dirige a ember-page-title, ember-welcome-page y ember-source, respectivamente. Incluso cuando las cosas están implícitas (por ejemplo, ambigüedad en llaves dobles, resolución de módulo, inyección de servicio), podemos adivinar el origen de un activo con alta precisión, gracias a las sólidas convenciones de Ember.

2. Modificación de código

Aun así, no deberíamos verificar cada archivo en cada paquete manualmente. Esto requiere mucho tiempo y es propenso a errores.

En su lugar, escribimos un codemod (en realidad, un linter) usando @codemod-utils. Para cada paquete, el codemod analiza lo que es relevante y crea una lista de dependencias que deberían estar presentes ("reales"). Luego compara la lista con la de package.json ("esperado").

Para analizar el código implícito, es necesario que haya una lista de activos conocidos (una creación única), que asigne cada paquete que queremos considerar a sus activos. Podemos usar un mapa para registrar esa información.

const KNOWN_ASSETS = new Map([
  [
    'ember-intl',
    {
      helpers: [
        'format-date',
        'format-list',
        'format-message',
        'format-number',
        'format-relative',
        'format-time',
        't',
      ],
      services: ['intl'],
    },
  ],
  [
    'ember-page-title',
    {
      helpers: ['page-title'],
      services: ['page-title'],
    },
  ],
  [
    'ember-welcome-page',
    {
      components: ['welcome-page'],
    },
  ],
]);

Ahora, debido a cómo funciona Ember, un análisis ingenuo de las declaraciones de importación puede generar falsos positivos. Tomemos el siguiente ejemplo:

import Route from '@ember/routing/route';
import fetch from 'fetch';

Cuando no proporcionamos el contexto correcto (es decir, este código es para Ember), el codemod consideraría @ember/routing y fetch como dependencias, en lugar de ember-source y (probablemente) ember-fetch. El codemod debe presentar su análisis de tal manera que podamos comprobar fácilmente si hay falsos positivos.

// Results for my-package-37

{
  missingDependencies: [
    'ember-asset-loader',
    'ember-truth-helpers'
  ],
  unusedDependencies: [
    '@babel/core',
    'ember-auto-import',
    'ember-cli-babel'
  ],
  unknowns: [
    'Services - host-router (addon/routes/registration.ts)',
  ]
}

3. Resultados

El codemod que había construido (en un par de días) analizó un repositorio de producción con 129 paquetes en 49 segundos. Había un total de 12.377 archivos, pero el codemod sólo supo analizar 6.013 de ellos (menos de la mitad). ¡Eso es un promedio de 0,008 segundos/archivo y 0,38 segundos/paquete!

Para obtener más información sobre cómo escribir codemods, consulta el tutorial principal de @codemod-utils.