|
1 | | -# Select Bundle Mode |
| 1 | +# Build Patterns |
| 2 | + |
| 3 | +The library has different build methods and options. You can choose a proper build method based on the scenario. In these section, we will introduce some common build patterns and when to use them. |
| 4 | + |
| 5 | +## bundle / bundleless |
| 6 | + |
| 7 | +So first let's understand bundle and bundleless. |
| 8 | + |
| 9 | +A bundle is a package of build artifacts, which may be a single file or multiple files based on a certain [code splitting strategy](https://esbuild.github.io/api/#splitting). |
| 10 | + |
| 11 | +bundleless, on the other hand, means that each source file is compiled and built separately, but not bundled together. Each output file can be found with its corresponding source code file. The process of **bundleless build can also be understood as the process of code conversion of source files only**. |
| 12 | + |
| 13 | +They have their own benefits. |
| 14 | + |
| 15 | +- bundle can reduce the size of build artifacts and also pre-package dependencies to reduce the size of installed dependencies. Packaging libraries in advance can speed up application project builds. |
| 16 | +- bundleless maintains the original file structure and is more conducive to debugging and tree shaking. |
| 17 | + |
| 18 | +:::warning |
| 19 | +bundleless is a single-file compilation mode, so for referencing and exporting types, you need to add the `type` keyword. For example, `import type { A } from './types'`. Please refer to the [esbuild documentation](https://esbuild.github.io/content-types/#isolated-modules) for more information. |
| 20 | +::: |
| 21 | + |
| 22 | +In `buildConfig` you can specify whether the current build task is bundle or bundleless by using [`buildConfig.buildType`](/en/api/config/build-config#buildtype). |
| 23 | + |
| 24 | +## ESM / CJS |
| 25 | + |
| 26 | +Library authors need to carefully consider which module formats to support. Let's understand ESM (ECMAScript Modules) and CJS (CommonJS) and when to use them. |
| 27 | + |
| 28 | +### What are ESM and CJS? |
| 29 | + |
| 30 | +- ESM is a modern module system introduced in ES2015 that allows JavaScript code to be organized into reusable, self-contained modules. ESM is now the standard for both [browser](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules) and [Node.js](https://nodejs.org/api/esm.html) environments, replacing older module systems like [CommonJS (CJS)](https://nodejs.org/api/modules.html) and [AMD](https://requirejs.org/docs/whyamd.html). |
| 31 | + |
| 32 | +- [CommonJS](https://nodejs.org/api/modules.html#modules-commonjs-modules) is a module system- used in JavaScript, particularly in server-side environments like Node.js. It was created to allow JavaScript to be used outside of the browser by providing a way to manage modules and dependencies. |
| 33 | + |
| 34 | +### When to support which format? |
| 35 | + |
| 36 | +For modern libraries, it's recommended to: |
| 37 | + |
| 38 | +1. **Default to ESM** |
| 39 | + |
| 40 | + - ESM is the future of JavaScript modules |
| 41 | + - Better tree-shaking support |
| 42 | + - Native browser support |
| 43 | + - Top-level await support |
| 44 | + |
| 45 | +2. **Consider CJS if:** |
| 46 | + |
| 47 | + - Supporting older Node.js versions (`<12.x`) |
| 48 | + - Supporting tools/frameworks that don't fully support ESM |
| 49 | + - Having users with CommonJS-only dependencies |
| 50 | + |
| 51 | +3. **Support both formats** |
| 52 | + |
| 53 | + - To maximize compatibility, you can build both formats: |
| 54 | + 1. Output ESM files with `.mjs` extension |
| 55 | + 2. Output CJS files with `.cjs` extension |
| 56 | + 3. Configure package.json with: |
| 57 | + ```json |
| 58 | + { |
| 59 | + "type": "module", |
| 60 | + "exports": { |
| 61 | + "import": "./dist/index.mjs", |
| 62 | + "require": "./dist/index.cjs" |
| 63 | + } |
| 64 | + } |
| 65 | + ``` |
0 commit comments