Окружающая среда API

Experimental

API окружающей среды экспериментально. Во время Vite 6 мы сохраним конюшню APIS, чтобы позволить экосистеме экспериментировать и построить на ней. Мы планируем стабилизировать эти новые API с потенциальными нарушающими изменениями в Vite 7.

Ресурсы:

• Обсуждение обратной связи, где мы собираем отзывы о новых API.
• Environment API PR , где новый API был реализован и рассмотрен.

Пожалуйста, поделитесь с нами своими отзывами.

Формализация Сред

VITE 6 формализует концепцию сред. До VITE 5 было две неявные среды ( client , и, необязательно, ssr ). Новая API среды позволяет пользователям и авторам Framework создавать столько средств, сколько необходимо для картирования того, как их приложения работают в производстве. Эта новая возможность потребовала большого внутреннего рефакторинга, но было приложено много усилий для обратной совместимости. Первоначальная цель VITE 6 - переместить экосистему в новую мажор как можно более плавную, задерживая принятие этих новых экспериментальных API, пока достаточное количество пользователей не перенесло достаточное количество пользователей, а авторы плагинов и авторы плагинов подтвердили новый дизайн.

Закрытие Разрыва Между Сборкой И Разработкой

Для простого спа/МПа никаких новых API в средах не подвергается воздействию конфигурации. Внутренне, Vite будет применять варианты к среде client , но не нужно знать об этой концепции при настройке VITE. Конфигурация и поведение от Vite 5 должны работать здесь плавно.

Когда мы переходим к типичному приложению на стороне сервера (SSR), у нас будет две среды:

• client : запускает приложение в браузере.
• server : Запускает приложение в узле (или другое время выполнения сервера), которое отображает страницы перед отправкой в браузер.

В Dev Vite выполняет код сервера в том же процессе узла, что и сервер Vite Dev, что дает близкое приближение к производственной среде. Тем не менее, для серверов также возможно работать в других временах JS, таких как работник Cloudflare , которые имеют разные ограничения. Современные приложения могут также работать в более чем двух средах, например, браузер, сервер узлов и сервер Edge. VITE 5 не позволил правильно представлять эти среды.

VITE 6 позволяет пользователям настраивать свое приложение во время сборки и разработки для картирования всех окружающих средств. Во время DEV один сервер Vite Dev теперь можно использовать для одновременного запуска кода в нескольких различных средах. Исходный код приложения все еще преобразуется с помощью Vite Dev Server. Помимо общего HTTP -сервера, среднего уровня, разрешенного конфигурации и плагинов, сервер Vite Dev теперь имеет набор независимых сред. Каждый из них настроен, чтобы соответствовать производственной среде максимально близко, и подключается к среде выполнения DEV, где выполняется код (для работника код сервера теперь может работать в Miniflare локально). В клиенте браузер импортирует и выполняет код. В других средах бегун модуля получает и оценивает преобразованный код.

Конфигурация Среды

Для спа -салона/MPA конфигурация будет выглядеть аналогично Vite 5. Внутренне эти параметры используются для настройки среды client .

export default defineConfig({
  build: {
    sourcemap: false,
  },
  optimizeDeps: {
    include: ['lib'],
  },
})

Это важно, потому что мы хотели бы сохранить доступ к VITE и избегать разоблачения новых концепций, пока они не будут необходимы.

Если приложение состоит из нескольких сред, эти среды могут быть явно настроены с опцией environments конфигурации.

export default {
  build: {
    sourcemap: false,
  },
  optimizeDeps: {
    include: ['lib'],
  },
  environments: {
    server: {},
    edge: {
      resolve: {
        noExternal: true,
      },
    },
  },
}

Если не явно задокументирована, среда наследует настроенные параметры конфигурации верхнего уровня (например, новые среды server и edge будут наследовать вариант build.sourcemap: false ). Небольшое количество вариантов верхнего уровня, например, optimizeDeps , применяется только к client среде, поскольку они не работают хорошо при применении в качестве среды по умолчанию к серверным средам. Среда client также может быть настроена явно через environments.client , но мы рекомендуем сделать это с опциями верхнего уровня, чтобы конфигурация клиента оставалась неизменной при добавлении новых сред.

Интерфейс EnvironmentOptions раскрывает все варианты окружающей среды. Есть варианты среды, которые применяются как к build , так и к dev , например, resolve . И есть DevEnvironmentOptions и BuildEnvironmentOptions для DEV и создают конкретные варианты (например, dev.warmup или build.outDir ). Некоторые варианты, такие как optimizeDeps применяются только к DEV, но сохраняются как верхний уровень, а не вложенные в dev для обратной совместимости.

interface EnvironmentOptions {
  define?: Record<string, any>
  resolve?: EnvironmentResolveOptions
  optimizeDeps: DepOptimizationOptions
  consumer?: 'client' | 'server'
  dev: DevOptions
  build: BuildOptions
}

Интерфейс UserConfig выходит из интерфейса EnvironmentOptions , позволяя настроить клиента и по умолчанию для других сред, настроенных через environments опции. client и серверная среда с именем ssr всегда присутствуют во время разработки. Это обеспечивает обратную совместимость с server.ssrLoadModule(url) и server.moduleGraph . Во время сборки среда client всегда присутствует, а среда ssr присутствует только в том случае, если она явно настроена (с использованием environments.ssr или для обратной совместимости build.ssr ). Приложению не нужно использовать имя ssr для своей среды SSR, оно может назвать, например, server

interface UserConfig extends EnvironmentOptions {
  environments: Record<string, EnvironmentOptions>
  // Другие варианты
}

Обратите внимание, что свойство ssr уровня будет устареть после стабильного API окружающей среды. Эта опция играет ту же роль, что и environments , но для среды по умолчанию ssr и позволила только настройка небольшого набора параметров.

Пользовательские Экземпляры Среды

Доступны API конфигурации низкого уровня, поэтому поставщики времени выполнения могут предоставить среды с надлежащими значениями по умолчанию для своего времени выполнения. Эти среды также могут породить другие процессы или потоки для запуска модулей во время DEV в ближайшем времени выполнения до производственной среды.

import { customEnvironment } from 'vite-environment-provider'

export default {
  build: {
    outDir: '/dist/client',
  },
  environments: {
    ssr: customEnvironment({
      build: {
        outDir: '/dist/ssr',
      },
    }),
  },
}

Обратная Совместимость

Текущий API Vite Server еще не устарел и обратно совместимы с Vite 5. Новая среда API является экспериментальным.

server.moduleGraph возвращает смешанное представление о графах клиента и модулей SSR. Обратные совместимые с комбинируемыми узлами смешанных модулей будут возвращены из всех его методов. Та же схема используется для узлов модуля, передаваемых до handleHotUpdate .

Мы еще не рекомендуем переходить на API окружающей среды. Мы стремимся к значительной части пользовательской базы, чтобы принять VITE 6, поэтому плагины не должны поддерживать две версии. Ознакомьтесь с разделом «Будущие нарушения разрыва для получения информации о будущих детективах и пути обновления»:

• this.environment в крючках
• HMR hotUpdate плагин крюк
• Перейти к API-интерфейсам для каждого окружающей среды
• SSR с использованием ModuleRunner API
• Общие плагины во время сборки

Целевые Пользователи

Это руководство предоставляет основные концепции среды для конечных пользователей.

Авторы плагинов имеют более согласованный API, доступный для взаимодействия с текущей конфигурацией среды. Если вы создаете на вершине VITE, руководство плагинов API Environment API описывает, как расширенные API плагина доступны для поддержки нескольких пользовательских сред.

Фреймворки могут решить выставить окружающую среду на разных уровнях. Если вы являетесь автором структуры, продолжите чтение Руководства API API Environment API , чтобы узнать о программной стороне API среды.

Руководство по провайдерам среды Runtimes Environment Times объясняет, как предложить пользовательскую среду для использования фреймворками и пользователями.