CI/CD для компонентных систем

Компонентные системы, построенные с использованием Lit, требуют особого подхода к автоматизации разработки и развертывания. В отличие от традиционных приложений, где CI/CD охватывает сборку, тестирование и деплой целого проекта, компонентные библиотеки нуждаются в отдельной обработке каждого элемента, их интеграции и публикации в репозитории компонентов или npm-пакетах.

Настройка сборки компонентов

Для сборки Lit-компонентов используется комбинация инструментов:

  1. Vite / Rollup — для модульной сборки, минимизации и поддержки ES-модулей.
  2. TypeScript — при использовании типизации, совместно с Rollup-plugin-typescript2 или аналогами.
  3. CSS и шаблоны — Lit позволяет инкапсулировать стили через css и unsafeCSS. CI/CD должен гарантировать, что CSS корректно обрабатывается и интегрируется в выходной пакет.

Пример конфигурации Rollup для Lit:

import resolve from '@rollup/plugin-node-resolve';
import commonjs from '@rollup/plugin-commonjs';
import typescript from 'rollup-plugin-typescript2';
import { terser } from 'rollup-plugin-terser';

export default {
  input: 'src/index.ts',
  output: [
    {
      file: 'dist/bundle.js',
      format: 'es',
      sourcemap: true
    }
  ],
  plugins: [
    resolve(),
    commonjs(),
    typescript(),
    terser()
  ]
};

Ключевой момент: сборка должна быть идемпотентной — одинаковый исходный код всегда генерирует одинаковый артефакт. Это важно для последующего кэширования и публикации.

Тестирование компонентов

Тестирование разделяется на несколько уровней:

  1. Unit-тесты с использованием Jest или Vitest. Для Lit важен тест рендеринга шаблонов и реактивных свойств:
import { html, fixture, expect } from '@open-wc/testing';
import '../src/my-component.js';

describe('my-component', () => {
  it('рендерит правильный текст', async () => {
    const el = await fixture(html`<my-component></my-component>`);
    expect(el.shadowRoot.textContent).to.include('Hello');
  });
});

  1. Visual regression testing с Percy или Chromatic для проверки изменений стилей и отображения компонентов.

  2. Accessibility testing через axe-core или Pa11y, так как компонентная библиотека должна быть доступна без дополнительных исправлений.

Все тесты должны выполняться в CI-пайплайне до публикации компонентов.

Управление версиями и публикация

CI/CD для компонентной системы требует управления версиями компонентов отдельно от приложения. Используется подход SemVer:

  • patch — исправление багов внутри компонента;
  • minor — добавление функционала, не нарушающего совместимость;
  • major — изменения API компонентов.

Для автоматической публикации в npm применяются инструменты типа changesets или semantic-release. Они анализируют коммиты и автоматически генерируют версию и CHANGELOG.

name: Release Components
on:
  push:
    branches:
      - main
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: pnpm/action-setup@v2
        with:
          version: 8
      - run: pnpm install
      - run: pnpm test
      - run: pnpm build
      - uses: semantic-release/semantic-release@v20

Интеграция с приложениями

Компоненты Lit часто используются в разных приложениях. CI/CD должен учитывать:

  • Публикацию сборок в npm с тегами (latest, beta, next) для безопасного тестирования.
  • Generation of package artifacts — CommonJS, ESM и Types для TypeScript.
  • Поддержку monorepo, если компоненты и приложения находятся в одном репозитории. В этом случае Lerna или Turborepo помогают разделять сборку и публикацию каждого пакета.

Автоматическое тестирование интеграций

Для проверки совместимости компонентов с реальными приложениями выполняются integration tests:

  • Поднимается мини-приложение через Playwright или Cypress.
  • Проверяется подключение компонентов через npm-пакет.
  • Отслеживаются ошибки Shadow DOM, стили и взаимодействия.

Кэширование и ускорение пайплайнов

CI/CD должен минимизировать время сборки:

  • Кэширование node_modules.
  • Кэширование сборок Rollup/Vite.
  • Инкрементальная сборка для monorepo через Turborepo или Nx.

Эти меры позволяют выполнять тесты и сборку компонентов быстро, без полной пересборки всех пакетов.

Мониторинг и отчётность

Пайплайн CI/CD должен собирать метрики:

  • Процент тестового покрытия компонентов.
  • Время сборки и тестирования.
  • Количество багов и regressions на визуальные тесты.

Интеграция с GitHub Actions, GitLab CI или Jenkins позволяет отправлять уведомления о статусе сборки и публикации в Slack или email, обеспечивая прозрачность процесса разработки.

Практика деплоя

Для фронтенд-приложений, использующих Lit, распространён подход:

  1. Публикация компонентов в npm.
  2. Автоматическое обновление зависимостей приложения через Renovate или Dependabot.
  3. Деплой приложения на staging, где тестируется поведение новых версий компонентов.
  4. Продакшен-деплой при успешных тестах и одобрении.

Эта схема обеспечивает плавную интеграцию компонентных обновлений без нарушения работы существующих приложений.

Оглавление