vite-env-only

Vite plugins for isolating server-only and client-only code

Install

1npm install -D vite-env-only

Deny Imports

Prevents specific packages and files from being included in the client or server bundle by throwing an error at build-time when a matching import would have been included.

1// vite.config.ts
2import { defineConfig } from "vite"
3import { denyImports } from "vite-env-only"
4
5export default defineConfig({
6  plugins: [
7    denyImports({
8      client: {
9        specifiers: ["fs-extra", /^node:/, "@prisma/*"],
10        files: ["**/.server/*", "**/*.server.*"],
11      },
12      server: {
13        specifiers: ["jquery"],
14      },
15    }),
16  ],
17})

1{
2  client?: {
3    specifiers?: Array<string | RegExp>,
4    files?: Array<string | RegExp>
5  },
6  server?: {
7    specifiers?: Array<string | RegExp>,
8    files?: Array<string | RegExp>
9  }
10}

specifiers

Matching is performed against the raw import specifier in the source code. Match patterns can be:

• String literal for exact matches
• Globs via micromatch
• RegExps

files

Matching is performed against the resolved and normalized root-relative file path. Match patterns can be:

• String literal for exact matches
• Globs via micromatch
• RegExps

Macros

1// vite.config.ts
2import { defineConfig } from "vite"
3import { envOnlyMacros } from "vite-env-only"
4
5export default defineConfig({
6  plugins: [envOnlyMacros()],
7})

All macros can be imported within your app code from "vite-env-only/macros".

serverOnly$

Marks an expression as server-only and replaces it with undefined on the client. Keeps the expression as-is on the server.

For example:

1import { serverOnly$ } from "vite-env-only/macros"
2
3export const message = serverOnly$("i only exist on the server")

On the client this produces:

1export const message = undefined

On the server this produces:

1export const message = "i only exist on the server"

clientOnly$

Marks an expression as client-only and replaces it with undefined on the server. Keeps the expression as-is on the client.

For example:

1import { clientOnly$ } from "vite-env-only/macros"
2
3export const message = clientOnly$("i only exist on the client")

On the client this produces:

1export const message = "i only exist on the client"

On the server this produces:

1export const message = undefined

Dead-code elimination

This plugin eliminates any identifiers that become unreferenced as a result of macro replacement.

For example, given the following usage of serverOnly$:

1import { serverOnly$ } from "vite-env-only/macros"
2import { readFile } from "node:fs"
3
4function readConfig() {
5  return JSON.parse(readFile.sync("./config.json", "utf-8"))
6}
7
8export const serverConfig = serverOnly$(readConfig())

On the client this produces:

1export const serverConfig = undefined

On the server this produces:

1import { readFile } from "node:fs"
2
3function readConfig() {
4  return JSON.parse(readFile.sync("./config.json", "utf-8"))
5}
6
7export const serverConfig = readConfig()

Type safety

The macro types capture the fact that values can be undefined depending on the environment.

For example:

1import { serverOnly$ } from "vite-env-only/macros"
2
3export const API_KEY = serverOnly$("secret")
4//           ^? string | undefined

If you want to opt out of strict type safety, you can use a non-null assertion (!):

1import { serverOnly$ } from "vite-env-only/macros"
2
3export const API_KEY = serverOnly$("secret")!
4//           ^? string

Why?

Vite already provides import.meta.env.SSR which works in a similar way to these macros in production. However, in development Vite neither replaces import.meta.env.SSR nor performs dead-code elimination as Vite considers these steps to be optimizations.

In general, its a bad idea to rely on optimizations for correctness. In contrast, these macros treat code replacement and dead-code elimination as part of their feature set.

Additionally, these macros use function calls to mark expressions as server-only or client-only. That means they can guarantee that code within the function call never ends up in the wrong environment while only transforming a single AST node type: function call expressions.

import.meta.env.SSR is instead a special identifier which can show up in many different AST node types: if statements, ternaries, switch statements, etc. This makes it far more challenging to guarantee that dead-code completely eliminated.

Prior art

Thanks to these project for exploring environment isolation and conventions for transpilation:

• esm-env
• Qwik
• TanStack bling