Top Related Projects
Next-generation ES module bundler
An extremely fast bundler for the web
Compile a Node.js project into a single file. Supports TypeScript, binary addons, dynamic requires.
The simplest and fastest way to bundle your TypeScript libraries.
The zero configuration build tool for the web. 📦🚀
ESM-powered frontend build tool. Instant, lightweight, unbundled development. ✌️
Quick Overview
Microbundle is a zero-configuration bundler for tiny modules, powered by Rollup. It's designed to make creating and publishing modern JavaScript libraries easier, with a focus on producing small, efficient bundles for various module formats (CommonJS, UMD, and ESM).
Pros
- Zero-configuration: Works out of the box for most projects without requiring setup
- Multiple output formats: Generates CommonJS, UMD, and ESM bundles automatically
- TypeScript support: Built-in handling of TypeScript files without additional configuration
- Small bundle sizes: Optimized for producing minimal bundle sizes
Cons
- Limited customization: May not be suitable for complex projects requiring extensive configuration
- Dependency on Rollup: Issues or limitations in Rollup can affect Microbundle
- Learning curve: While simple to use, understanding all features and optimizations may take time
Code Examples
- Basic usage:
// src/index.js
export const greet = (name) => `Hello, ${name}!`;
- Using with TypeScript:
// src/index.ts
export function add(a: number, b: number): number {
return a + b;
}
- Exporting multiple functions:
// src/index.js
export const multiply = (a, b) => a * b;
export const divide = (a, b) => a / b;
Getting Started
- Install Microbundle:
npm install --save-dev microbundle
- Add scripts to your
package.json
:
{
"scripts": {
"build": "microbundle",
"dev": "microbundle watch"
}
}
- Run the build command:
npm run build
This will create optimized bundles in the dist
directory, ready for distribution.
Competitor Comparisons
Next-generation ES module bundler
Pros of Rollup
- More flexible and customizable with a wide range of plugins
- Better suited for larger projects and complex build configurations
- Supports code splitting and dynamic imports
Cons of Rollup
- Steeper learning curve, especially for beginners
- Requires more manual configuration and setup
- May be overkill for small projects or simple libraries
Code Comparison
Microbundle configuration:
{
"scripts": {
"build": "microbundle"
}
}
Rollup configuration:
import resolve from '@rollup/plugin-node-resolve';
import commonjs from '@rollup/plugin-commonjs';
export default {
input: 'src/index.js',
output: {
file: 'dist/bundle.js',
format: 'cjs'
},
plugins: [resolve(), commonjs()]
};
Summary
Microbundle is designed for simplicity and ease of use, making it ideal for small to medium-sized projects and quick setups. It provides sensible defaults and requires minimal configuration.
Rollup offers more power and flexibility, making it suitable for larger projects and complex build requirements. It allows for fine-grained control over the bundling process but requires more setup and configuration.
Choose Microbundle for rapid development and simple libraries, while opt for Rollup when you need advanced features, code splitting, or custom build pipelines.
An extremely fast bundler for the web
Pros of esbuild
- Significantly faster build times due to its Go-based implementation
- Supports a wider range of modern JavaScript features out of the box
- More actively maintained with frequent updates and improvements
Cons of esbuild
- Less focus on producing small bundle sizes compared to microbundle
- Steeper learning curve for configuration and customization
- Limited plugin ecosystem compared to microbundle's Rollup-based approach
Code Comparison
microbundle configuration:
{
"scripts": {
"build": "microbundle"
}
}
esbuild configuration:
const esbuild = require('esbuild');
esbuild.build({
entryPoints: ['src/index.js'],
outfile: 'dist/bundle.js',
bundle: true,
minify: true,
}).catch(() => process.exit(1));
microbundle focuses on simplicity and ease of use, requiring minimal configuration for most projects. esbuild offers more granular control over the build process but may require more setup for complex scenarios.
Both tools aim to simplify the bundling process for JavaScript projects, but they take different approaches. microbundle is designed for creating small, optimized packages with minimal configuration, while esbuild prioritizes speed and modern JavaScript support, making it suitable for larger projects and development environments where build performance is crucial.
Compile a Node.js project into a single file. Supports TypeScript, binary addons, dynamic requires.
Pros of ncc
- Faster build times, especially for larger projects
- Creates a single file output, simplifying deployment
- Built-in tree-shaking for smaller bundle sizes
Cons of ncc
- Less flexible configuration options
- May not handle certain edge cases as well as microbundle
- Limited support for multiple entry points
Code Comparison
ncc:
const ncc = require('@vercel/ncc')
ncc(entry, {
minify: true,
sourceMap: false
}).then(({ code, map, assets }) => {
console.log(code)
})
microbundle:
const microbundle = require('microbundle')
microbundle({
input: 'src/index.js',
output: 'dist/bundle.js',
format: ['cjs', 'umd', 'es']
}).then(() => console.log('Build complete'))
Both ncc and microbundle are popular tools for bundling JavaScript projects, but they serve slightly different purposes. ncc is focused on creating a single file output with minimal configuration, making it ideal for simple projects or serverless functions. microbundle, on the other hand, offers more flexibility and supports multiple output formats, making it better suited for library authors or complex projects with specific bundling requirements.
The simplest and fastest way to bundle your TypeScript libraries.
Pros of tsup
- Faster build times due to esbuild integration
- Native TypeScript support without additional configuration
- Simpler CLI interface for quick setups
Cons of tsup
- Less mature and potentially less stable than microbundle
- Fewer configuration options for advanced use cases
- Limited support for older JavaScript environments
Code Comparison
tsup:
import { defineConfig } from 'tsup'
export default defineConfig({
entry: ['src/index.ts'],
format: ['cjs', 'esm'],
dts: true,
})
microbundle:
{
"scripts": {
"build": "microbundle",
"dev": "microbundle watch"
},
"source": "src/index.js",
"main": "dist/foo.js",
"module": "dist/foo.mjs",
"unpkg": "dist/foo.umd.js"
}
Both tsup and microbundle aim to simplify the process of bundling JavaScript/TypeScript libraries. tsup leverages esbuild for faster builds and offers native TypeScript support, making it attractive for TypeScript projects. However, microbundle provides more extensive configuration options and better support for older JavaScript environments. The choice between the two depends on project requirements, build speed priorities, and the need for specific output formats or configurations.
The zero configuration build tool for the web. 📦🚀
Pros of Parcel
- Zero configuration out of the box, making it easier for beginners
- Supports a wide range of file types and assets without additional plugins
- Faster build times due to multicore processing and caching
Cons of Parcel
- Less customizable than Microbundle for specific use cases
- Larger bundle sizes for smaller projects compared to Microbundle
- Can be overkill for simple library projects
Code Comparison
Parcel:
{
"scripts": {
"start": "parcel index.html",
"build": "parcel build index.html"
}
}
Microbundle:
{
"scripts": {
"build": "microbundle",
"dev": "microbundle watch"
}
}
Parcel requires no configuration file, while Microbundle uses a minimal configuration approach. Parcel is more suited for full application bundling, whereas Microbundle is optimized for creating small, efficient library bundles.
Parcel shines in its simplicity and broad asset support, making it ideal for rapid prototyping and larger applications. Microbundle, on the other hand, excels in creating optimized packages for libraries and smaller modules, offering more control over the bundling process.
Choose Parcel for quick setup and diverse asset handling in larger projects. Opt for Microbundle when building libraries or when fine-tuned control over bundle size and output formats is crucial.
ESM-powered frontend build tool. Instant, lightweight, unbundled development. ✌️
Pros of Snowpack
- Faster development experience with no-bundle approach
- Built-in support for modern web features like ES modules
- Optimized production builds with automatic code-splitting
Cons of Snowpack
- Larger learning curve for developers used to traditional bundlers
- Less mature ecosystem compared to established bundlers
- May require additional configuration for complex projects
Code Comparison
Snowpack configuration:
// snowpack.config.js
module.exports = {
mount: {
public: '/',
src: '/dist',
},
plugins: ['@snowpack/plugin-react-refresh'],
};
Microbundle configuration:
// package.json
{
"source": "src/index.js",
"main": "dist/index.js",
"module": "dist/index.module.js",
"unpkg": "dist/index.umd.js"
}
Snowpack focuses on a no-bundle development approach, providing a faster development experience and leveraging modern web features. It offers optimized production builds with automatic code-splitting. However, it may have a steeper learning curve for developers accustomed to traditional bundlers and has a less mature ecosystem.
Microbundle, on the other hand, is a zero-configuration bundler that aims to simplify the process of creating and publishing JavaScript packages. It provides a more familiar experience for developers used to traditional bundling workflows but may not offer the same level of development speed and modern web feature support as Snowpack.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Microbundle
The zero-configuration bundler for tiny modules, powered by Rollup.
Guide â Setup ⯠Formats ⯠Modern Mode ⯠Usage & Configuration ⯠All Options
⨠Features
- One dependency to bundle your library using only a
package.json
- Support for ESnext & async/await (via Babel & async-to-promises)
- Produces tiny, optimized code for all inputs
- Supports multiple entry modules (
cli.js
+index.js
, etc) - Creates multiple output formats for each entry (CJS, UMD & ESM)
- 0 configuration TypeScript support
- Built-in Terser compression & gzipped bundle size tracking
ð§ Installation & Setup
1ï¸â£ Install by running: npm i -D microbundle
2ï¸â£ Set up your package.json
:
{
"name": "foo", // your package name
"type": "module",
"source": "src/foo.js", // your source code
"exports": {
"require": "./dist/foo.cjs", // used for require() in Node 12+
"default": "./dist/foo.modern.js" // where to generate the modern bundle (see below)
},
"main": "./dist/foo.cjs", // where to generate the CommonJS bundle
"module": "./dist/foo.module.js", // where to generate the ESM bundle
"unpkg": "./dist/foo.umd.js", // where to generate the UMD bundle (also aliased as "umd:main")
"scripts": {
"build": "microbundle", // compiles "source" to "main"/"module"/"unpkg"
"dev": "microbundle watch" // re-build when source files change
}
}
3ï¸â£ Try it out by running npm run build
.
ð½ Output Formats
Microbundle produces esm
, cjs
, umd
bundles with your code compiled to syntax that works pretty much everywhere.
While it's possible to customize the browser or Node versions you wish to support using a browserslist configuration, the default setting is optimal and strongly recommended.
ð¤ Modern Mode
In addition to the above formats, Microbundle also outputs a modern
bundle specially designed to work in all modern browsers.
This bundle preserves most modern JS features when compiling your code, but ensures the result runs in 95% of web browsers without needing to be transpiled.
Specifically, it uses Babel's "bugfixes" mode
(previously known as preset-modules) to target the set of browsers that support <script type="module">
- that allows syntax like async/await, tagged templates, arrow functions, destructured and rest parameters, etc.
The result is generally smaller and faster to execute than the plain esm
bundle.
Take the following source code for example:
// Our source, "src/make-dom.js":
export default async function makeDom(tag, props, children) {
let el = document.createElement(tag);
el.append(...(await children));
return Object.assign(el, props);
}
Compiling the above using Microbundle produces the following modern
and esm
bundles:
make-dom.modern.js (117b) |
make-dom.module.js (194b) |
---|---|
|
|
This is enabled by default. All you have to do is add an "exports"
field to your package.json
:
{
"main": "./dist/foo.umd.js", // legacy UMD output (for Node & CDN use)
"module": "./dist/foo.module.mjs", // legacy ES Modules output (for bundlers)
"exports": "./dist/foo.modern.mjs", // modern ES2017 output
"scripts": {
"build": "microbundle src/foo.js"
}
}
The "exports"
field can also be an object for packages with multiple entry modules:
{
"name": "foo",
"exports": {
".": "./dist/foo.modern.mjs", // import "foo" (the default)
"./lite": "./dist/lite.modern.mjs", // import "foo/lite"
"./full": "./dist/full.modern.mjs" // import "foo/full"
},
"scripts": {
"build": "microbundle src/*.js" // build foo.js, lite.js and full.js
}
}
ð¦ Usage & Configuration
Microbundle includes two commands - build
(the default) and watch
.
Neither require any options, but you can tailor things to suit your needs a bit if you like.
microbundle
â bundles your code once and exits. (alias:microbundle build
)microbundle watch
â bundles your code, then re-bundles when files change.
â¹ï¸ Microbundle automatically determines which dependencies to inline into bundles based on your
package.json
.Read more about How Microbundle decides which dependencies to bundle, including some example configurations.
Specifying filenames in package.json
Unless overridden via the command line, microbundle uses the source
property in your package.json
to determine which of your JavaScript files to start bundling from (your "entry module").
The filenames and paths for generated bundles in each format are defined by the main
, umd:main
, module
and exports
properties in your package.json
.
{
"source": "src/index.js", // input
"main": "dist/foo.js", // CommonJS output bundle
"umd:main": "dist/foo.umd.js", // UMD output bundle
"module": "dist/foo.mjs", // ES Modules output bundle
"exports": {
"types": "./dist/foo.d.ts", // TypeScript typings for NodeNext modules
"require": "./dist/foo.js", // CommonJS output bundle
"default": "./dist/foo.modern.mjs", // Modern ES Modules output bundle
},
"types": "dist/foo.d.ts" // TypeScript typings
}
When deciding which bundle to use, Node.js 12+ and webpack 5+ will prefer the exports
property, while older Node.js releases use the main
property, and other bundlers prefer the module
field.
For more information about the meaning of the different properties, refer to the Node.js documentation.
For UMD builds, microbundle will use a camelCase version of the name
field in your package.json
as export name.
Alternatively, this can be explicitly set by adding an "amdName"
key in your package.json
, or passing the --name
command line argument.
Usage with {"type":"module"}
in package.json
Node.js 12.16+ adds a new "ES Module package", which can be enabled by adding {"type":"module"}
to your package.json.
This property changes the default source type of .js
files to be ES Modules instead of CommonJS.
When using {"type":"module"}
, the file extension for CommonJS bundles generated by Microbundle must be changed to .cjs
:
{
"type": "module",
"module": "dist/foo.js", // ES Module bundle
"main": "dist/foo.cjs", // CommonJS bundle
}
Additional Configuration Options
Config also can be overridded by the publishConfig
property in your package.json
.
{
"main": "src/index.ts", // this would be used in the dev environment (e.g. Jest)
"publishConfig": {
"source": "src/index.js", // input
"main": "dist/my-library.js", // output
},
"scripts": {
"build": "microbundle"
}
}
Building a single bundle with fixed output name
By default Microbundle outputs multiple bundles, one bundle per format. A single bundle with a fixed output name can be built like this:
microbundle -i lib/main.js -o dist/bundle.js --no-pkg-main -f umd
Using with TypeScript
Just point the input to a .ts
file through either the cli or the source
key in your package.json
and youâre done.
Microbundle will generally respect your TypeScript config defined in a tsconfig.json
file with notable exceptions being the "target" and "module" settings. To ensure your TypeScript configuration matches the configuration that Microbundle uses internally it's strongly recommended that you set "module": "ESNext"
and "target": "ESNext"
in your tsconfig.json
.
To ensure Microbundle does not process extraneous files, by default it only includes your entry point. If you want to include other files for compilation, such as ambient declarations, make sure to add either "files" or "include" into your tsconfig.json
.
If you're using TypeScript with CSS Modules, you will want to set "include": ["node_modules/microbundle/index.d.ts"]
in your tsconfig.json
to tell TypeScript how to handle your CSS Module imports.
To ensure that your module's .d.ts
type info is visible to other TypeScript projects that use moduleResolution: 'NodeNext'
, add a types
key to your package.json
's corresponding exports
mapping.
CSS and CSS Modules
Importing CSS files is supported via import "./foo.css"
. By default, generated CSS output is written to disk. The --css inline
command line option will inline generated CSS into your bundles as a string, returning the CSS string from the import:
// with the default external CSS:
import './foo.css'; // generates a minified .css file in the output directory
// with `microbundle --css inline`:
import css from './foo.css';
console.log(css); // the generated minified stylesheet
CSS Modules: CSS files with names ending in .module.css
are treated as a CSS Modules.
To instead treat imported .css
files as modules, run Microbundle with --css-modules true
. To disable CSS Modules for your project, pass --no-css-modules
or --css-modules false
.
The default scope name for CSS Modules is_[name]__[local]__[hash:base64:5]
in watch mode, and _[hash:base64:5]
for production builds.
This can be customized by passing the command line argument --css-modules "[name]_[hash:base64:7]"
, using these fields and naming conventions.
flag | import | is css module? |
---|---|---|
null | import './my-file.css'; | :x: |
null | import './my-file.module.css'; | :white_check_mark: |
false | import './my-file.css'; | :x: |
false | import './my-file.module.css'; | :x: |
true | import './my-file.css'; | :white_check_mark: |
true | import './my-file.module.css'; | :white_check_mark: |
Building Module Workers
Microbundle is able to detect and bundle Module Workers when generating bundles in the
esm
and modern
formats. To use this feature, instantiate your Web Worker as follows:
worker = new Worker(new URL('./worker.js', import.meta.url), { type: 'module' });
// or simply:
worker = new Worker('./worker.js', { type: 'module' });
... then add the --workers
flag to your build command:
microbundle --workers
For more information see @surma/rollup-plugin-off-main-thread.
Visualize Bundle Makeup
Use the --visualize
flag to generate a stats.html
file at build time, showing the makeup of your bundle. Uses rollup-plugin-visualizer.
Mangling Properties
To achieve the smallest possible bundle size, libraries often wish to rename internal object properties or class members to smaller names - transforming this._internalIdValue
to this._i
. Microbundle doesn't do this by default, however it can be enabled by creating a mangle.json
file (or a "mangle"
property in your package.json). Within that file, you can specify a regular expression pattern to control which properties should be mangled. For example: to mangle all property names beginning an underscore:
{
"mangle": {
"regex": "^_"
}
}
It's also possible to configure repeatable short names for each mangled property, so that every build of your library has the same output. See the wiki for a complete guide to property mangling in Microbundle.
Defining build-time constants
The --define
option can be used to inject or replace build-time constants when bundling. In addition to injecting string or number constants, prefixing the define name with @
allows injecting JavaScript expressions.
Build command | Source code | Output |
---|---|---|
microbundle --define VERSION=2 | console.log(VERSION) | console.log(2) |
microbundle --define API_KEY='abc123' | console.log(API_KEY) | console.log("abc123") |
microbundle --define @assign=Object.assign | assign(a, b) | Object.assign(a, b) |
All CLI Options
Usage
$ microbundle <command> [options]
Available Commands
build Build once and exit
watch Rebuilds on any change
For more info, run any command with the `--help` flag
$ microbundle build --help
$ microbundle watch --help
Options
-v, --version Displays current version
-i, --entry Entry module(s)
-o, --output Directory to place build files into
-f, --format Only build specified formats (any of modern,esm,cjs,umd or iife) (default modern,esm,cjs,umd)
-w, --watch Rebuilds on any change (default false)
--pkg-main Outputs files analog to package.json main entries (default true)
--target Specify your target environment (node or web) (default web)
--external Specify external dependencies, or 'none' (default peerDependencies and dependencies in package.json)
--globals Specify globals dependencies, or 'none'
--define Replace constants with hard-coded values (use @key=exp to replace an expression)
--alias Map imports to different modules
--compress Compress output using Terser (default true when --target is web, false when --target is node)
--strict Enforce undefined global context and add "use strict"
--name Specify name exposed in UMD and IIFE builds
--cwd Use an alternative working directory (default .)
--sourcemap Generate source map (default true)
--raw Show raw byte size (default false)
--jsx A custom JSX pragma like React.createElement (default h)
--jsxFragment A custom JSX fragment pragma like React.Fragment (default Fragment)
--jsxImportSource Declares the module specifier to be used for importing jsx factory functions
--tsconfig Specify the path to a custom tsconfig.json
--generateTypes Whether or not to generate types, if `types` or `typings` is set in `package.json` then it will default to be `true`
--css Where to output CSS: "inline" or "external" (default "external")
--css-modules Configures .css to be treated as modules (default null)
--workers Bundle module workers - see https://github.com/surma/rollup-plugin-off-main-thread#auto-bundling (default false)
--visualize Generate bundle makeup visualization (stats.html)
-h, --help Displays this message
Examples
$ microbundle build --globals react=React,jquery=$
$ microbundle build --define API_KEY=1234
$ microbundle build --alias react=preact/compat
$ microbundle watch --no-sourcemap # don't generate sourcemaps
$ microbundle build --tsconfig tsconfig.build.json
ð£ Roadmap
Here's what's coming up for Microbundle:
ð¨ Built with Microbundle
- Preact Fast 3kB React alternative with the same modern API. Components & Virtual DOM.
- Stockroom Offload your store management to a worker easily.
- Microenvi Bundle, serve, and hot reload with one command.
- Theme UI Build consistent, themeable React apps based on constraint-based design principles.
- react-recomponent Reason-style reducer components for React using ES6 classes.
- react-hooks-lib A set of reusable react hooks.
- mdx-deck-live-code A library for mdx-deck to do live React and JS coding directly in slides.
- react-router-ext An Extended react-router-dom with simple usage.
- routex.js A dynamic routing library for Next.js.
- hooked-form A lightweight form-management library for React.
- goober Less than 1KB css-in-js alternative with a familiar API.
- react-model The next generation state management library for React.
- Teaful Tiny, easy and powerful (P)React state management.
- @studio-freight/lenis Tiny, Performant, Vanilla JS, Smooth Scroll library.
- @studio-freight/tempus One rAF to rule them all.
- @studio-freight/hamo Collection of React hooks.
- glTF Transform Library for working with .gltf and .glb 3D models.
- eta Lightweight, powerful, pluggable embedded JS template engine
- swup Page transition library for server-rendered websites.
ð¥ License
Top Related Projects
Next-generation ES module bundler
An extremely fast bundler for the web
Compile a Node.js project into a single file. Supports TypeScript, binary addons, dynamic requires.
The simplest and fastest way to bundle your TypeScript libraries.
The zero configuration build tool for the web. 📦🚀
ESM-powered frontend build tool. Instant, lightweight, unbundled development. ✌️
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot