Tanto o Embroider quanto o pnpm pedem que os pacotes declarem suas dependências corretamente: Liste uma dependência (se e somente) se ela for usada.

Isso é difícil de fazer ao trabalhar em um monorepo grande (considere um aplicativo Ember com muitos complementos Ember e pacotes Node) que usa yarn@v1. Os desenvolvedores podem esquecer de atualizar o package.json, porque o aplicativo Ember pode ser compilado e executado mesmo quando uma dependência está faltando, desde que seja extraído de outro pacote.

Portanto, nem build nem run podem nos dizer se algum pacote não declarou suas dependências corretamente. De que outra forma podemos consertar o package.json para que possamos apresentar o Embroider e o pnpm?

1. Análise estática de código

Dado um arquivo, podemos ver quais dependências devem estar presentes, porque sabemos como JavaScript e Ember funcionam.

Por exemplo, se um arquivo JavaScript (ou TypeScript) fosse exibido,

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 dizer pelas declarações de importação que o pacote depende de ember-intl e ember-qunit.

E, se um arquivo de modelo fosse exibido,

{{page-title "My App"}}



{{outlet}}

nosso conhecimento do Ember e seu ecossistema de complementos nos direciona para ember-page-title, ember-welcome-page e ember-source, respectivamente. Mesmo quando as coisas estão implícitas (por exemplo, ambigüidade entre chaves duplas, resolução de módulo, injeção de serviço), podemos adivinhar a origem de um ativo com alta precisão, graças às fortes convenções do Ember.

2. Código mod

Ainda assim, não devemos verificar todos os arquivos de todos os pacotes manualmente. Isso é demorado e sujeito a erros.

Em vez disso, escrevemos um codemod (na verdade, um linter) usando @codemod-utils. Para cada pacote, o codemod analisa o que é relevante e cria uma lista de dependências que devem estar presentes ("reais"). Em seguida, ele compara a lista com a de package.json ("esperado").

Para analisar o código implícito, é necessário haver uma lista de ativos conhecidos (uma criação única), que mapeia cada pacote que queremos considerar para seus ativos. Podemos usar um mapa para registrar essas informações.

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'],
    },
  ],
]);

Agora, devido à forma como o Ember funciona, uma análise ingênua das declarações de importação pode levar a falsos positivos. Veja o seguinte exemplo:

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

Quando não fornecemos o contexto correto (ou seja, este código é para Ember), o codemod consideraria @ember/routing e fetch como dependências, em vez de ember-source e (provavelmente) ember-fetch. O codemod deve apresentar sua análise de forma que possamos facilmente verificar se há 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

O codemod que eu construí (em alguns dias) analisou um repositório de produção com 129 pacotes em 49 segundos. Foram ao todo 12.377 arquivos, mas o codemod soube analisar apenas 6.013 deles (menos da metade). Isso é uma média de 0,008 segundos/arquivo e 0,38 segundos/pacote!

Para saber mais sobre como escrever codemods, confira o tutorial principal de @codemod-utils.