Package Exports

@visulima/packem
@visulima/packem/builder/typedoc
@visulima/packem/config
@visulima/packem/dts/isolated/transformer/oxc
@visulima/packem/dts/isolated/transformer/swc
@visulima/packem/dts/isolated/transformer/typescript
@visulima/packem/package.json
@visulima/packem/transformer/esbuild
@visulima/packem/transformer/sucrase
@visulima/packem/transformer/swc

Readme

Visulima Packem

A fast and modern bundler for Node.js and TypeScript.
Supports multiple runtimes, shared modules, server components, dynamic import, wasm, css, and more.
Built on top of Rollup, combined with your preferred transformer like esbuild, swc, or sucrase.

^{Daniel Bannert's open source work is supported by the community on GitHub Sponsors}

Overview

Visulima Packem is built on top of Rollup, combined with your preferred transformer like esbuild, swc, or sucrase. It enables you to generate multiple bundles (CommonJS or ESModule) simultaneously while adhering to Node.js’ native file type support.

It uses the exports configuration in package.json and recognizes entry file conventions to match your exports and build them into bundles.

Features

✅ package.json#exports, package.json#main, package.json#module to define entry-points
✅ package.json#bin to define executables
✅ package.json#types to define types
✅ Generates package.json#typeVersions to support node 10
✅ Dependency externalization
✅ Minification
✅ TypeScript support + .d.ts bundling
✅ Watch mode
✅ CLI outputs (auto hashbang insertion)
✅ Validates package.json and checks if all fields that are needed to publish your package are configured correctly
✅ Supports multiple runtimes (default, react-server, edge-light)
✅ Supports react server and client components
✅ Supports shared modules
✅ Supports dynamic import
✅ Supports tsconfig.json paths and package.json imports resolution
✅ ESM ⇄ CJS interoperability
✅ Supports isolated declaration types (experimental)
✅ Supports wasm WebAssembly modules
✅ Supports css and css modules (coming soon)
✅ TypeDoc documentation generation

And more...

Install

npm install --save-dev @visulima/packem

yarn add -D @visulima/packem

pnpm add -D @visulima/packem

Prepare your project

You need to prepare your project to be able to bundle it with packem.

You can check out the following cases to configure your package.json.

JavaScript

Then use the exports field in package.json to configure different conditions and leverage the same functionality as other bundlers, such as webpack. The exports field allows you to define multiple conditions.

{
    "files": ["dist"],
    "exports": {
        "import": "./dist/index.mjs",
        "require": "./dist/index.cjs"
    },
    "scripts": {
        "build": "packem build"
    }
}

TypeScript

When building a TypeScript library, separate the types from the main entry file by specifying the types path in package.json. When you're using .mjs or .cjs extensions with TypeScript and modern module resolution (above node16), TypeScript will require specific type declaration files like .d.mts or .d.cts to match the extension. packem can automatically generate them to match the types to match the condition and extensions. One example is to configure your exports like this in package.json:

{
    "files": ["dist"],
    "exports": {
        "import": {
            "types": "./dist/index.d.mts",
            "default": "./dist/index.mjs"
        },
        "require": {
            "types": "./dist/index.d.cts",
            "default": "./dist/index.cjs"
        }
    },
    "scripts": {
        "build": "packem build"
    }
}

Hybrid (CJS & ESM) Module Resolution with TypeScript

If you're using TypeScript with Node 10 and Node 16 module resolution, you can use the types field in package.json to specify the types path. Then packem will generate the types file with the same extension as the main entry file.

{
    "files": ["dist"],
    "main": "./dist/index.cjs",
    "module": "./dist/index.mjs",
    "types": "./dist/index.d.ts",
    "exports": {
        "import": {
            "types": "./dist/index.d.mts",
            "default": "./dist/index.mjs"
        },
        "require": {
            "types": "./dist/index.d.cts",
            "default": "./dist/index.cjs"
        }
    },
    "scripts": {
        "build": "packem build"
    }
}

Enable the automatic node 10 typesVersions generation in packem.config.js:

export default defineConfig({
    // ...
    rollup: {
        // ...
        node10Compatibility: {
            typeScriptVersion: ">=5.0", // Chose the version of TypeScript you want to support
            writeToPackageJson: true,
        },
        // ...
    },
    transformer,
});

You can validate your package.json exports configuration with are the types wrong cli tool.

Links:

https://github.com/frehner/modern-guide-to-packaging-js-library#set-the-main-field

Usage

Initialize the packem configuration

Initialize packem in your project, this will create a packem.config.ts or packem.config.js file in the root of your project.

packem init [options]

This command will ask you some questions about your project and create the configuration file.

Bundle files

Run the following command to bundle your files:

packem build [options]

Then files in src folders will be treated as entry files and match the export names in package.json.

[!NOTE] The src folder can be configured in the packem configuration file.

For example: src/index.ts will match the exports name "." or the only main export.

Now just run npm run build or pnpm build / yarn build if you're using these package managers, packem will find the entry files and build them. The output format will be based on the exports condition and also the file extension. Given an example:

It's CommonJS for require and ESM for import based on the exports condition.
It's CommonJS for .cjs and ESM for .mjs based on the extension regardless the exports condition. Then for export condition like "node" you could choose the format with your extension.

[!NOTE] All the dependencies and peerDependencies will be marked as external automatically and not included in the bundle. If you want to include them in the bundle, you can use the --no-external option.

This will write the files into the ./dist folder.

[!NOTE] The dist folder can be configured in the packem configuration file.

Multiple Runtime

For exports condition like react-native, react-server and edge-light as they're special platforms, they could have different exports or different code conditions. In this case packem provides an override input source file convention if you want to build them as different code bundle.

For instance:

{
    "exports": {
        "react-server": "./dist/react-server.mjs",
        "edge-light": "./dist/edge-light.mjs",
        "import": "./dist/index.mjs"
    }
}

[!NOTE] The edge-light export contains a process.env.EdgeRuntime variable true, for all other runtimes false is returned.

`production` and `development` exports condition

If you need to separate the production and development exports condition, packem provides process.env.NODE_ENV injected by default if present that you don't need to manually inject yourself.

When the production exports condition is defined and the file ends with *.production.* in the package.json, the bundle will be minified.
When the development exports condition is defined and the file ends with *.development.* in the package.json, the bundle will not be minified.

{
    "exports": {
        "development": "./dist/index.development.mjs",
        "production": "./dist/index.production.mjs"
    }
}

Executables

To build executable files with the bin field in package.json. The source file matching will be same as the entry files convention.

[!NOTE] > packem automatically preserves and prepends the shebang to the executable file, and fix correct permissions for the executable file.

For example:

|- src/
  |- bin/
    |- index.ts

This will match the bin field in package.json as:

{
    "bin": "./dist/bin/index.cjs"
}

or .mjs if the type field is module in package.json.

{
    "type": "module",
    "bin": "./dist/bin/index.mjs"
}

For multiple executable files, you can create multiple files.

|- src/
  |- bin/
    |- foo.ts
    |- bar.ts

This will match the bin field in package.json as:

{
    "bin": {
        "foo": "./dist/bin/foo.cjs",
        "bar": "./dist/bin/bar.cjs"
    }
}

Server Components

packem supports to build server components and server actions with library directives like "use client" or "use server". It will generate the corresponding chunks for client and server that scope the client and server boundaries properly. Then when the library is integrated to an app such as Next.js, app bundler can transform the client components and server actions correctly and maximum the benefits.

If you're using "use client" or "use server" in entry file, then it will be preserved on top and the dist file of that entry will become a client component. If you're using "use client" or "use server" in a file that used as a dependency for an entry, then that file containing directives be split into a separate chunk and hoist the directives to the top of the chunk.

Shared Modules (Experimental)

There are always cases that you need to share code among bundles, but they don't have to be a separate entry or exports. You want to have them bundled into a shared chunk and then use them in different bundles. You can use shared module convention [name].[layer]-runtime.[ext] to create shared modules bundles.

Shared Utils Example

// src/util.shared-runtime.js
export function sharedUtil() {
    /* ... */
}

Then you can use them in different entry files:

// src/index.js
import { sharedUtil } from "./util.shared-runtime";

// src/lite.js
import { sharedUtil } from "./util.shared-runtime";

packem will bundle the shared module into a separate layer which matches the file name convention, in the above case it's "shared", and that bundle will be referenced by the different entry bundles.

With multiple runtime bundles, such as having default and react-server together. They could have the modules that need to be shared and kept as only one instance among different runtime bundles. You can use the shared module convention to create shared modules bundles for different runtime bundles.

Shared Runtime Module Example

"use client";
// src/app-context.shared-runtime.js
export const AppContext = React.createContext(null);

Then you can use them in different entry files:

// src/index.js
import { AppContext } from "./app-context.shared-runtime";

// src/index.react-server.js
import { AppContext } from "./app-context.shared-runtime";

app-context.shared-runtime will be bundled into a separate chunk that only has one instance and be shared among different runtime bundles.

Text or Data Files

packem supports importing of file as string content, you can name the extension as .txt or .data, and it will be bundled as string content.

// src/index.js
import { text } from "./text.txt";

console.log(text); // "Hello World"

Visualize Bundle Makeup

Use the --visualize flag to generate a packem-bundle-analyze.html file at build time, showing the makeup of your bundle.

Building Module Workers (Experimental) (WIP)

packem supports building module workers with the --workers flag, which are a special type of bundle that can be used to run code in a web worker.

worker = new Worker(new URL("./worker.js", import.meta.url), { type: "module" });
// or simply:
worker = new Worker("./worker.js", { type: "module" });

CSS and CSS Modules (Coming Soon)

Aliases

Aliases can be configured in the import map, defined in package.json#imports.

For native Node.js import mapping, all entries must be prefixed with # to indicate an internal subpath import. Packem takes advantage of this behavior to define entries that are not prefixed with # as an alias.

Native Node.js import mapping supports conditional imports (eg. resolving different paths for Node.js and browser), but packem does not.

⚠️ Aliases are not supported in type declaration generation. If you need type support, do not use aliases.

{
    // ...

    imports: {
        // Mapping '~utils' to './src/utils.js'
        "~utils": "./src/utils.js",

        // Native Node.js import mapping (can't reference ./src)
        "#internal-package": "./vendors/package/index.js",
    },
}

ESM ⇄ CJS interoperability

Node.js ESM offers interoperability with CommonJS via static analysis. However, not all bundlers compile ESM to CJS syntax in a way that is statically analyzable.

Because packem uses Rollup, it's able to produce CJS modules that are minimal and interoperable with Node.js ESM.

This means you can technically output in CommonJS to get ESM and CommonJS support.

`require()` in ESM

Sometimes it's useful to use require() or require.resolve() in ESM. ESM code that uses require() can be seamlessly compiled to CommonJS, but when compiling to ESM, Node.js will error because require doesn't exist in the module scope.

When compiling to ESM, packem detects require() usages and shims it with createRequire(import.meta.url).

Not only does packem shim ESM ⇄ CJS, but fixes the export and export types for default exports in your commonjs files.

To enable both features you need to add cjsInterop: true to your packem config.

export default defineConfig({
    cjsInterop: true,
    // ...
});

Environment variables

Pass in compile-time environment variables with the --env flag.

This will replace all instances of process.env.NODE_ENV with 'production' and remove unused code:

packem build --env.NODE_ENV=production

Validating

Packem validates your package.json file and checks if all fields are configured correctly, that are needed to publish your package.

[!NOTE] To have a full validation checkup, visit publint and are the types wrong.

TypeDoc

Installation

To generate api documentation for your project, you need to install typedoc to your project.

npm exec packem add typedoc

yarn exec packem add typedoc

pnpm exec packem add typedoc

To generate documentation for your project, you can use the --typedoc flag.

packem build --typedoc

This will generate a api-docs folder in the root of your project.

Different formats

You can specify the output format inside the packem.config.js file.

export default defineConfig({
    // ...
    typedoc: {
        format: "inline",
        readmePath: "./README.md",
    },
    // ...
});

Configuration

packem.config.js

The packem configuration file is a JavaScript file that exports an object with the following properties:

transformer

You choose which one of the three supported transformer to use.

Api Docs

cli

config

Functions

defineConfig()

function defineConfig(config): BuildConfig | BuildConfigFunction

Define a build configuration.

definePreset()

function definePreset(preset): BuildPreset

Define a build preset.

Parameters

• preset: BuildPreset

Returns

BuildPreset

Defined in

config.ts:24

Type Aliases

BuildConfigFunction()

type BuildConfigFunction: (enviroment, mode) => BuildConfig | Promise<BuildConfig>;

Parameters

• enviroment: Environment

• mode: Mode

Returns

BuildConfig | Promise<BuildConfig>

Defined in

config.ts:3

References

BuildConfig

Re-exports BuildConfig

BuildHooks

Re-exports BuildHooks

BuildPreset

Re-exports BuildPreset

packem

Functions

packem()

function packem(
   rootDirectory, 
   mode, 
   environment, 
   logger, 
inputConfig): Promise<void>

Parameters

• rootDirectory: string

• mode: Mode

• environment: Environment

• logger: PailServerType

• inputConfig: object & BuildConfig = {}

Returns

Promise<void>

Defined in

packem.ts:610

Interfaces

BuildConfig

In addition to basic entries, presets, and hooks, there are also all the properties of BuildOptions except for BuildOption's entries.

Extends

DeepPartial<Omit<BuildOptions, "entries">>

Properties

alias?

optional alias: DeepPartial<Record<string, string>>;

Inherited from

DeepPartial.alias

Defined in

types.ts:181

analyze?

optional analyze: DeepPartial<boolean>;

Inherited from

DeepPartial.analyze

Defined in

types.ts:182

builder?

optional builder: DeepPartial<Record<string, (context, cachePath, fileCache, logged) => Promise<void>>>;

Inherited from

DeepPartial.builder

Defined in

types.ts:183

cjsInterop?

optional cjsInterop: DeepPartial<boolean>;

Inherited from

DeepPartial.cjsInterop

Defined in

types.ts:184

clean?

optional clean: DeepPartial<boolean>;

Inherited from

DeepPartial.clean

Defined in

types.ts:185

debug?

optional debug: DeepPartial<boolean>;

Inherited from

DeepPartial.debug

Defined in

types.ts:186

declaration?

optional declaration: DeepPartial<boolean | "compatible" | "node16">;

compatible means "src/gather.ts" will generate "dist/index.d.mts", "dist/index.d.cts" and "dist/index.d.ts". node16 means "src/gather.ts" will generate "dist/index.d.mts" and "dist/index.d.cts". true is equivalent to compatible. false will disable declaration generation. undefined will auto-detect based on "package.json". If "package.json" has "types" field, it will be "compatible", otherwise false.

Inherited from

DeepPartial.declaration

Defined in

types.ts:194

dtsOnly?

optional dtsOnly: DeepPartial<boolean>;

optional entries: (string | BuildEntry)[];

Defined in

types.ts:309

externals?

optional externals: DeepPartial<string | RegExp>[];

Inherited from

DeepPartial.externals

Defined in

types.ts:203

failOnWarn?

optional failOnWarn: DeepPartial<boolean>;

Inherited from

DeepPartial.failOnWarn

Defined in

types.ts:204

fileCache?

optional fileCache: DeepPartial<boolean>;

Inherited from

DeepPartial.fileCache

Defined in

types.ts:205

hooks?

optional hooks: Partial<BuildHooks>;

Defined in

types.ts:310

isolatedDeclarationTransformer?

optional isolatedDeclarationTransformer: DeepPartial<(code, id) => Promise<IsolatedDeclarationsResult>>;

Experimental

Inherited from

DeepPartial.isolatedDeclarationTransformer

Defined in

types.ts:207

jiti?

optional jiti: DeepPartial<Omit<JitiOptions, "transform" | "onError">>;

optional preset: "none" | "auto" | BuildPreset | object & string;

Defined in

types.ts:311

rollup?

optional rollup: DeepPartial<RollupBuildOptions>;

Inherited from

DeepPartial.rollup

Defined in

types.ts:215

rootDir?

optional rootDir: string;

Inherited from

DeepPartial.rootDir

Defined in

types.ts:216

sourceDir?

optional sourceDir: string;

Inherited from

DeepPartial.sourceDir

Defined in

types.ts:217

sourcemap?

optional sourcemap: DeepPartial<boolean>;

Inherited from

DeepPartial.sourcemap

Defined in

types.ts:218

transformer?

optional transformer: DeepPartial<(config) => Plugin<any>>;

Inherited from

DeepPartial.transformer

Defined in

types.ts:219

typedoc?

optional typedoc: DeepPartial<false | TypeDocumentOptions>;

Inherited from

DeepPartial.typedoc

Defined in

types.ts:220

validation?

optional validation: DeepPartial<object>;

Type declaration

packageJson?

optional packageJson: object;

packageJson.bin?

optional bin: boolean;

packageJson.dependencies?

optional dependencies: boolean;

packageJson.exports?

optional exports: boolean;

packageJson.files?

optional files: boolean;

packageJson.main?

optional main: boolean;

packageJson.module?

optional module: boolean;

packageJson.name?

optional name: boolean;

packageJson.types?

optional types: boolean;

packageJson.typesVersions?

optional typesVersions: boolean;

Inherited from

DeepPartial.validation

Defined in

types.ts:221

BuildContext

Properties

buildEntries

buildEntries: (BuildContextBuildEntry | BuildContextBuildAssetAndChunk)[];

Defined in

types.ts:288

dependencyGraphMap

dependencyGraphMap: Map<string, Set<[string, string]>>;

Defined in

types.ts:289

environment

environment: Environment;

Defined in

types.ts:290

hooks

hooks: Hookable<BuildHooks, HookKeys<BuildHooks>>;

Defined in

types.ts:291

jiti

jiti: Jiti;

Defined in

types.ts:292

logger

logger: PailServerType;

Defined in

types.ts:293

mode

mode: Mode;

Defined in

types.ts:294

options

options: InternalBuildOptions;

Defined in

types.ts:295

pkg

pkg: PackageJson<!-- TYPEDOC -->;

Defined in

types.ts:296

tsconfig?

optional tsconfig: TsConfigResult;

Defined in

types.ts:297

usedImports

usedImports: Set<string>;

Defined in

types.ts:298

warnings

warnings: Set<string>;

Defined in

types.ts:299

BuildHooks

Properties

build:before()

build:before: (context) => void | Promise<void>;

Parameters

• context: BuildContext

Returns

void | Promise<void>

Defined in

types.ts:237

build:done()

build:done: (context) => void | Promise<void>;

Parameters

• context: BuildContext

Returns

void | Promise<void>

Defined in

types.ts:238

build:prepare()

build:prepare: (context) => void | Promise<void>;

Parameters

• context: BuildContext

Returns

void | Promise<void>

Defined in

types.ts:239

builder:before()

builder:before: (name, context) => void | Promise<void>;

Parameters

• name: string

• context: BuildContext

Returns

void | Promise<void>

Defined in

types.ts:241

builder:done()

builder:done: (name, context) => void | Promise<void>;

Parameters

• name: string

• context: BuildContext

Returns

void | Promise<void>

Defined in

types.ts:242

rollup:build()

rollup:build: (context, build) => void | Promise<void>;

Parameters

• context: BuildContext

• build: RollupBuild

Returns

void | Promise<void>

Defined in

types.ts:244

rollup:done()

rollup:done: (context) => void | Promise<void>;

Parameters

• context: BuildContext

Returns

void | Promise<void>

Defined in

types.ts:245

rollup:dts:build()

rollup:dts:build: (context, build) => void | Promise<void>;

Parameters

• context: BuildContext

• build: RollupBuild

Returns

void | Promise<void>

Defined in

types.ts:246

rollup:dts:done()

rollup:dts:done: (context) => void | Promise<void>;

Parameters

• context: BuildContext

Returns

void | Promise<void>

Defined in

types.ts:248

rollup:dts:options()

rollup:dts:options: (context, options) => void | Promise<void>;

Parameters

• context: BuildContext

• options: RollupOptions

Returns

void | Promise<void>

Defined in

types.ts:249

rollup:options()

rollup:options: (context, options) => void | Promise<void>;

Parameters

• context: BuildContext

• options: RollupOptions

Returns

void | Promise<void>

Defined in

types.ts:251

rollup:watch()

rollup⌚ (context, watcher) => void | Promise<void>;

Parameters

• context: BuildContext

types.ts:260

BuildOptions

Properties

alias

alias: Record<string, string>;

Defined in

types.ts:181

analyze?

optional analyze: boolean;

Defined in

types.ts:182

builder?

optional builder: Record<string, (context, cachePath, fileCache, logged) => Promise<void>>;

Defined in

types.ts:183

cjsInterop?

optional cjsInterop: boolean;

Defined in

types.ts:184

clean

clean: boolean;

Defined in

types.ts:185

debug

debug: boolean;

Defined in

types.ts:186

declaration?

optional declaration: boolean | "compatible" | "node16";

Defined in

types.ts:194

dtsOnly?

optional dtsOnly: boolean;

optional isolatedDeclarationTransformer: (code, id) => Promise<IsolatedDeclarationsResult>;

Experimental

Parameters

• code: string

• id: string

Returns

Promise<IsolatedDeclarationsResult>

Defined in

types.ts:207

jiti

jiti: Omit<JitiOptions, "transform" | "onError">;

Jiti options, where jiti is used to load the entry files.

Defined in

types.ts:211

minify?

optional minify: boolean;

Defined in

types.ts:212

name

name: string;

Defined in

types.ts:213

outDir

outDir: string;

Defined in

types.ts:214

rollup

rollup: RollupBuildOptions;

Defined in

types.ts:215

rootDir

rootDir: string;

Defined in

types.ts:216

sourceDir

sourceDir: string;

Defined in

types.ts:217

sourcemap

sourcemap: boolean;

Defined in

types.ts:218

transformer()

transformer: (config) => Plugin<any>;

Parameters

• config: EsbuildPluginConfig | SucrasePluginConfig | SwcPluginConfig

Returns

Plugin<any>

Defined in

types.ts:219

typedoc

typedoc: false | TypeDocumentOptions;

Defined in

types.ts:220

validation?

optional validation: object;

packageJson?

optional packageJson: object;

packageJson.bin?

optional bin: boolean;

packageJson.dependencies?

optional dependencies: boolean;

packageJson.exports?

optional exports: boolean;

packageJson.files?

optional files: boolean;

packageJson.main?

optional main: boolean;

packageJson.module?

optional module: boolean;

packageJson.name?

optional name: boolean;

packageJson.types?

optional types: boolean;

packageJson.typesVersions?

optional typesVersions: boolean;

Defined in

types.ts:221

RollupBuildOptions

Properties

alias

alias: false | RollupAliasOptions;

Defined in

types.ts:104

cjsInterop?

optional cjsInterop: CJSInteropOptions;

Defined in

types.ts:105

commonjs

commonjs: false | RollupCommonJSOptions;

Defined in

types.ts:106

copy?

optional copy: false | CopyPluginOptions;

Defined in

types.ts:107

dts

dts: Options;

Defined in

types.ts:108

dynamicVars?

optional dynamicVars: false | RollupDynamicImportVariablesOptions;

Defined in

types.ts:109

esbuild

esbuild: false | Options;

Defined in

types.ts:110

isolatedDeclarations?

optional isolatedDeclarations: IsolatedDeclarationsOptions;

Defined in

types.ts:111

json

json: false | RollupJsonOptions;

Defined in

types.ts:112

jsxRemoveAttributes?

optional jsxRemoveAttributes: false | JSXRemoveAttributesPlugin;

Defined in

types.ts:113

license?

optional license: false | LicenseOptions;

Defined in

types.ts:114

metafile?

optional metafile: boolean;

Defined in

types.ts:115

node10Compatibility?

optional node10Compatibility: false | Node10CompatibilityOptions;

Defined in

types.ts:116

output?

optional output: OutputOptions;

Defined in

types.ts:117

patchTypes

patchTypes: false | PatchTypesOptions;

Defined in

types.ts:118

plugins?

optional plugins: RollupPlugins;

Defined in

types.ts:119

polyfillNode?

optional polyfillNode: false | NodePolyfillsOptions;

Defined in

types.ts:120

preserveDirectives?

optional preserveDirectives: object;

directiveRegex?

optional directiveRegex: RegExp;

exclude?

optional exclude: FilterPattern;

include?

optional include: FilterPattern;

Defined in

types.ts:121

preserveDynamicImports?

optional preserveDynamicImports: boolean;

Defined in

types.ts:126

raw?

optional raw: false | RawLoaderOptions;

Defined in

types.ts:127

replace

replace: false | RollupReplaceOptions;

Defined in

types.ts:128

resolve

resolve: false | RollupNodeResolveOptions;

Defined in

types.ts:129

shebang?

optional shebang: false | Partial<ShebangOptions>;

Defined in

types.ts:130

shim?

optional shim: false | EsmShimCjsSyntaxOptions;

Defined in

types.ts:131

sucrase?

optional sucrase: false | SucrasePluginConfig;

Defined in

types.ts:132

swc?

optional swc: false | SwcPluginConfig;

Defined in

types.ts:133

treeshake?

optional treeshake: boolean | TreeshakingPreset | TreeshakingOptions;

Defined in

types.ts:134

visualizer?

optional visualizer: false | PluginVisualizerOptions;

Defined in

types.ts:135

wasm?

optional wasm: false | RollupWasmOptions;

Defined in

types.ts:136

watch?

optional watch: false | WatcherOptions;

Defined in

types.ts:137

Type Aliases

BuildContextBuildAssetAndChunk

type BuildContextBuildAssetAndChunk: object;

Type declaration

bytes?

optional bytes: number;

chunk?

optional chunk: boolean;

chunks?

optional chunks: string[];

exports?

optional exports: string[];

modules?

optional modules: object[];

path

path: string;

type?

optional type: "asset" | "chunk";

Defined in

types.ts:273

BuildContextBuildEntry

type BuildContextBuildEntry: object;

Type declaration

bytes?

optional bytes: number;

chunk?

optional chunk: boolean;

chunks?

optional chunks: string[];

exports?

optional exports: string[];

modules?

optional modules: object[];

path

path: string;

type?

optional type: "entry";

Defined in

types.ts:263

BuildEntry

type BuildEntry: object;

Type declaration

cjs?

optional cjs: boolean;

declaration?

optional declaration: boolean | "compatible" | "node16";

environment?

optional environment: Environment;

esm?

optional esm: boolean;

executable?

optional executable: true;

exportKey?

optional exportKey: Set<string>;

fileAlias?

optional fileAlias: string;

input

input: string;

isGlob?

optional isGlob: boolean;

name?

optional name: string;

outDir?

optional outDir: string;

runtime?

optional runtime: Runtime;

Defined in

types.ts:165

BuildPreset

type BuildPreset: BuildConfig | () => BuildConfig;

Defined in

types.ts:302

Environment

type Environment: "production" | "development" | undefined;

Defined in

types.ts:90

Mode

type Mode: "build" | "jit" | "watch" | "tsdoc";

Defined in

types.ts:319

Runtime

type Runtime: "react-server" | "react-native" | "edge-light" | "node";

Defined in

types.ts:163

bunchee - Zero config bundler for ECMAScript and TypeScript packages
unbuild - 📦 An unified javascript build system
pkgroll - 📦 Zero-config package bundler for Node.js + TypeScript
siroc - Zero-config build tooling for Node
tsup - The simplest and fastest way to bundle your TypeScript libraries
microbundle - Zero-configuration bundler for tiny JS libs, powered by Rollup.

Supported Node.js Versions

Libraries in this ecosystem make the best effort to track Node.js’ release schedule. Here’s a post on why we think this is important.

Contributing

If you would like to help take a look at the list of issues and check our Contributing guild.

Note: please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.

Credits

License

The visulima pack is open-sourced software licensed under the MIT

@visulima/packem

Package Exports

Readme

Visulima Packem

Overview

Features

Install

Prepare your project

Usage

Initialize the packem configuration

Bundle files

Multiple Runtime

production and development exports condition

Executables

Server Components

Shared Modules (Experimental)

Text or Data Files

Visualize Bundle Makeup

Building Module Workers (Experimental) (WIP)

CSS and CSS Modules (Coming Soon)

Aliases

ESM ⇄ CJS interoperability

require() in ESM

Environment variables

Validating

TypeDoc

Installation

Different formats

Configuration

packem.config.js

transformer

Api Docs

cli

config

Functions

defineConfig()

Parameters

Returns

Defined in

definePreset()

Parameters

Returns

Defined in

Type Aliases

BuildConfigFunction()

Parameters

Returns

Defined in

References

BuildConfig

BuildHooks

BuildPreset

packem

Functions

packem()

Parameters

Returns

Defined in

Interfaces

BuildConfig

Extends

Properties

alias?

Inherited from

Defined in

analyze?

Inherited from

Defined in

builder?

Inherited from

Defined in

cjsInterop?

Inherited from

Defined in

clean?

Inherited from

Defined in

debug?

Inherited from

Defined in

`production` and `development` exports condition

`require()` in ESM