A Akira UI 3.0.0 parte três imports e mais nada

Uma app com três dependências instaladas por nada. Essa era a conta que a Akira UI passava a quem só queria navegação e overlays. No início de setembro, a integração Astro do payable-docs instalou recharts, @tanstack/react-table e react-hook-form para usar primitivas que não desenham um único gráfico, tabela ou formulário. Sem esses três pacotes, o bundler recusava:

Cannot find package recharts imported from node_modules/@akira-io/ui/dist/index.js

Desde a 1.1.0 que os três estão declarados como peers opcionais no manifesto. A entrada raiz importava os três de imediato. Opcional no papel, obrigatório na prática. A 3.0.0 corrige o contrato, e migrar são três linhas de import.

Havia um atalho, e ficou de lado

A app podia ter entrado em dist/ e importado o chunk que lhe interessava. Não o fez, e fez bem: chunks internos não são API pública e rebentam na primeira release que os reorganiza. Restava a superfície publicada, e a superfície publicada cobrava três pacotes na instalação.

O que muda no código

Nada, tirando o especificador. Cada export mudou de porta e manteve o nome, as props e as labels:

// antes, na 2.6.0
import { AreaChart, DataTable, Form } from '@akira-io/ui';

// depois, na 3.0.0
import { AreaChart } from '@akira-io/ui/charts';
import { DataTable } from '@akira-io/ui/data-table';
import { Form } from '@akira-io/ui/form';

ChartContainer, CHART_PALETTE, chartColorVariable, FacetedFilter, RowActionsMenu, FormField e os tipos Column, Row e ColumnDef acompanham o componente que servem. Quem não desenha nenhum dos três apaga três dependências e não reescreve mais nada.

Um teste percorre agora, no build, o grafo de imports das oito entradas da sua lista, ficheiros de declarações incluídos, e falha se alguma delas chegar a um dos três peers. Também verifica que cada export saiu da raiz e apareceu no seu subpath. A regressão que deu origem a isto não volta em silêncio.

Uma major por três imports

A objeção é justa: subir a major por causa de especificadores inflaciona o número. O versionamento semântico mede se o código do consumidor parte, não o tamanho do estrago. Aqui parte, logo a major é honesta, e a correção é um localizar e substituir em três nomes.

O que mudou foi a promessa por baixo do número. Na 2.6.0, uma app pagava por componentes que nunca desenhava. Na 3.0.0 paga pelo que importa.

O resto da tag

As passkeys entram como blocos componíveis: lista, item, botão de registo, botão de início de sessão e um ponto de entrada Inertia ligado ao @laravel/passkeys, para uma app Laravel montar o fluxo de credenciais sem repetir a coreografia do WebAuthn.

O calendário e o filtro de intervalo de datas seguem o locale de datas do provider em vez de fixarem português. Um default daqueles que só parece bom a quem o escreveu.

As cores das séries de um gráfico já não colidem quando duas chaves são sanitizadas para o mesmo nome de custom property. Esse fix estava pronto antes da tag da 2.6.0 e foi deixado de fora, porque a review mostrou que partia a tooltip e a legenda. Corrigido a sério, entra aqui.

O diálogo de configuração da autenticação em dois fatores é a razão pela qual a 3.0.0 saiu com um dia de atraso. O código QR crescia até ocupar o painel todo e empurrava o título e o botão Continuar para fora do ecrã. Apareceu na demo do site de documentação, não num teste nem numa queixa. Agora o QR fica num tamanho fixo dentro de uma moldura clara, a chave de configuração é um campo só de leitura com revelar e copiar, e o corpo do diálogo rola, com o título e a ação principal fora da zona de scroll.

Um peer opcional só é opcional quando a raiz não lhe toca.