huozhi / bunchee

Zero config bundler for ECMAScript and TypeScript packages

bunchee

Zero-config bundler for frontend libraries.

bunchee is a zero configuration bundler makes bundling JS/TS library effortless. It's built on top of Rollup and SWC ⚡️, allowing you to focus on writing code and generating multiple bundles (CommonJS or ESModule) at the same time. It uses the standard exports configuration in package.json as the only source of truth, and uses entry file conventions to match your exports and build them into bundles.

Quick Start

Installation

npm install --save-dev bunchee

If you're using TypeScript

npm install --save-dev bunchee typescript

Configuration

Create your library entry file and package.json.

cd ./my-lib
mkdir src && touch ./src/index.ts

Prepare

# Use bunchee to prepare package.json configuration
npm exec bunchee --prepare
# "If you're using other package manager such as pnpm"
# pnpm bunchee --prepare

# "Or use with npx"
# npx bunchee@latest --prepare

Or you can checkout the following cases to configure your package.json.

JavaScript

Then use 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/es/index.mjs",
    "require": "./dist/cjs/index.js"
  },
  "scripts": {
    "build": "bunchee"
  }
}

TypeScript

If you're build a TypeScript library, separate the types from the main entry file and specify 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. bunchee 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/es/index.d.mts",
      "default": "./dist/es/index.mjs"
    },
    "require": {
      "types": "./dist/cjs/index.d.ts",
      "default": "./dist/cjs/index.js"
    }
  },
  "scripts": {
    "build": "bunchee"
  }
}

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 `bunchee` will generate the types file with the same extension as the main entry file.

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

Build

Then files in src folders will be treated as entry files and match the export names in package.json. 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, bunchee will find the entry files and build them. The output format will 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 .js 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.

Usage

File Conventions

While exports field is becoming the standard of exporting in node.js, bunchee also supports to build multiple exports all in one command.

Provide entry files with the name ([name].[ext]) that matches the exported name from exports field in package.json. For instance:

• <cwd>/src/index.ts will match "." export name or the if there's only one main export.
• <cwd>/src/lite.ts will match "./lite" export name.

The build script can be just bunchee without configure any input sources for each exports. Of course you can still specify other arguments as you need. Briefly, the entry files from src/ folder will do matching with exports conditions from package.json and build them into bundles.

Assuming you have default export package as "." and subpath export "./lite" with different exports condition listed in package.json

{
  "name": "example",
  "scripts": {
    "build": "bunchee"
  },
  "exports": {
    "./lite": "./dist/lite.js",
    ".": {
      "import": "./dist/index.mjs",
      "require": "./dist/index.cjs"
    }
  }
}

Then you need to add two entry files index.ts and lite.ts in project root directory to match the export name "." and "./lite", bunchee will associate these entry files with export names then use them as input source and output paths information.

- my-lib/
  |- src/
    |- lite.ts
    |- index.ts
  |- package.json

It will also look up for index.<ext> file under the directory having the name of the export path. For example, if you have "./lite": "./dist/lite.js" in exports field, then it will look up for ./lite/index.js as the entry file as well.

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 bunchee 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"
  }
}

Executables

To build executable files with the bin field in package.json, bunchee requires you to create the bin directory under src directory. The source file matching will be same as the entry files convention.

For example:

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

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

{
  "bin": "./dist/bin.js"
}

For multiple executable files, you can create multiple files under the bin directory.

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

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

{
  "bin": {
    "foo": "./dist/bin/a.js",
    "bar": "./dist/bin/b.js"
  }
}

Note: For multiple bin files, the filename should match the key name in the bin field.

Server Components

bunchee 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

There're 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'

bunchee 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.

CLI

CLI Options

bunchee CLI provides few options to create different bundles or generating types.

• Output (-o <file>): Specify output filename.
• Format (-f <format>): Set output format (default: 'esm').
• External (--external <dep,>): Specifying extra external dependencies, by default it is the list of dependencies and peerDependencies from package.json. Values are separate by comma.
• Target (--target <target>): Set ECMAScript target (default: 'es2015').
• Runtime (--runtime <runtime>): Set build runtime (default: 'browser').
• Environment (--env <env,>): Define environment variables. (default: NODE_ENV, separate by comma)
• Working Directory (--cwd <cwd>): Set current working directory where containing package.json.
• Minify (-m): Compress output.
• Watch (-w): Watch for source file changes.
• No Clean(--no-clean): Do not clean the dist folder before building. (default: false)
• TSConfig (--tsconfig <path>): Specify the path to the TypeScript configuration file. (default: tsconfig.json)

cd <project-root-dir>

# specifying input, output and format

bunchee ./src/index.js -f cjs -o ./dist/bundle.js
bunchee ./src/index.js -f esm -o ./dist/bundle.esm.js

# build node.js library, or change target to es2019
bunchee ./src/index.js --runtime node --target es2019

Specifying extra external dependencies

By default, bunchee will mark all the dependencies and peerDependencies as externals so you don't need to pass them as CLI args. But if there's any dependency that used but not in the dependency list and you want to mark as external, you can use the --external option to specify them.

bunchee --external=dep1,dep2,dep3

Replace dep1, dep2, and dep3 with the names of the dependencies you want to exclude from the bundle.

Bundling everything without external dependencies

To bundle your library without external dependencies, use the --no-external option:

bunchee --no-external

This will include all dependencies within your output bundle.

Environment Variables

To pass environment variables to your bundled code, use the --env option followed by a comma-separated list of environment variable names:

bunchee --env=ENV1,ENV2,ENV3

Replace ENV1, ENV2, and ENV3 with the names of the environment variables you want to include in your bundled code. These environment variables will be inlined during the bundling process.

You can use index.<export-type>.<ext> to override the input source file for specific export name. Or using <export-path>/index.<export-type>.<ext> also works. Such as:

|- src/
  |- index/.ts
  |- index.react-server.ts
  |- index.edge-light.ts

This will match the export name "react-server" and "edge-light" then use the corresponding input source file to build the bundle.

Auto Development and Production Mode

process.env.NODE_ENV is injected by default if present that you don't need to manually inject yourself. If you need to separate the development build and production build, bunchee provides different export conditions for development and production mode with development and production export conditions.

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

Then you can use bunchee to build the development bundle and production bundle automatically.

CSS

bunchee has basic CSS support for pure CSS file imports. It will be bundled into js bundle and insert the style tag into the document head when the bundle is loaded by browser.

/* src/style.css */
.foo {
  color: orange;
}

// src/index.tsx
import './style.css'

export const Foo = () => <div className="foo">foo</div>

Text Files

If you just want to import a file as string content, you can name the extension as .txt or .data and it will be bundled as string content.

For example:

src/index.ts

import data from './data.txt'

export default data

src/data.txt

hello world

output

export default "hello world"

Node.js API

import path from 'path'
import { bundle, type BundleConfig } from 'bunchee'

// The definition of these options can be found in help information
await bundle(path.resolve('./src/index.ts'), {
  dts: false, // Boolean
  watch: false, // Boolean
  minify: false, // Boolean
  sourcemap: false, // Boolean
  external: [], // string[]
  format: 'esm', // 'esm' | 'cjs'
  target: 'es2015', // ES syntax target
  runtime: 'nodejs', // 'browser' | 'nodejs'
  cwd: process.cwd(), // string
  clean: true, // boolean
  tsconfig: 'tsconfig.json', // string
})

Watch Mode

Bunchee offers a convenient watch mode for rebuilding your library whenever changes are made to the source files. To enable this feature, use either -w or --watch.

target

If you specify target option in tsconfig.json, then you don't have to pass it again through CLI.

Package lint

bunchee has support for checking the package bundles are matched with package exports configuration.

License

MIT

bunchee's Issues

Resolve the regenerator-runtime path

with pnpm install, the path of regenerator might be not able to resolve, so we should always alias the one installed by bunchee

Build issues with 1.8.4

Hi, I tried to build a react project using Bunchee w/ v.1.8.4 and looks like there might be some syntax issue going on?

Repo: https://github.com/rive-app/rive-react

Change the default output syntax level

bunchee default output to es5, since IE11 is not supported officially anymore, the default output should change to es6 or even higher

Working with conditional exports

Hello! I'm working on a package that depends on the WebCrypto API, and I'd like to use require('node:crypto').webcrypto conditionally on Node.js environments.

Although my use case is quite a niche, I think using conditional exports enables useful things that weren't possible before: using N-API bindings on Node.js, providing Node.js-specific APIs and more.

Would you consider adding this feature? I'm not sure about the design, but I'm thinking something like a constant with the matched condition.

react18如果不引入react，打包会报错

Support getting target from tsconfig

Leverage the target setting from tsconfig.json

Compiling TypeScript with Iterable<T>

Hello @huozhi

I am trying to bundle a typescript file src/index.ts which contain code on iterables, i.e., Iterable<T> and IterableIterator<T> types are used. I have the package.json setup as mentioned.

I tried to compile it as follows:

$ bunchee src/index.ts

And recieved the following error:

C:\Documents\extra-array>bunchee -f esm --runtime node --target esnext src/index.ts                     
src/index.ts(161,14): error TS2802: Type 'Iterable<T>' can only be iterated through when using the '--downlevelIteration' flag or with a '--target' of 'es2015' or higher.
src/index.ts(171,36): error TS2802: Type 'Iterable<T>' can only be iterated through when using the '--downlevelIteration' flag or with a '--target' of 'es2015' or higher.
src/index.ts(848,10): error TS2802: Type 'IterableIterator<T[]>' can only be iterated through when using the '--downlevelIteration' flag or with a '--target' of 'es2015' or higher.
src/index.ts(849,17): error TS2802: Type 'IterableIterator<T[]>' can only be iterated through when using the '--downlevelIteration' flag or with a '--target' of 'es2015' or higher.
src/index.ts(868,12): error TS2802: Type 'IterableIterator<T[]>' can only be iterated through when using the '--downlevelIteration' flag or with a '--target' of 'es2015' or higher.
src/index.ts(876,19): error TS2802: Type 'IterableIterator<T[]>' can only be iterated through when using the '--downlevelIteration' flag or with a '--target' of 'es2015' or higher.
src/index.ts(1244,17): error TS2802: Type 'IterableIterator<number>' can only be iterated through when using the '--downlevelIteration' flag or with a '--target' of 'es2015' or higher.
src/index.ts(1260,17): error TS2802: Type 'IterableIterator<number>' can only be iterated through when using the '--downlevelIteration' flag or with a '--target' of 'es2015' or higher.
src/index.ts(1275,14): error TS2802: Type 'IterableIterator<number>' can only be iterated through when using the '--downlevelIteration' flag or with a '--target' of 'es2015' or higher.
src/index.ts(2287,15): error TS2802: Type 'Iterable<T>' can only be iterated through when using the '--downlevelIteration' flag or with a '--target' of 'es2015' or higher.

I retried the following commands, but recieved the same errors as above.

$ bunchee -f esm --runtime node --target es2015 src/index.ts
$ bunchee -f esm --runtime node --target es2018 src/index.ts
$ bunchee -f esm --runtime node --target esnext src/index.ts
$ bunchee -f esm --runtime node --target esnext --downlevelIteration src/index.ts

Maybe this has something to do with passing arguments to swc.

Regards.

Simplify multi exports compilation config

In v2 alpha we introduced a bunchee configuration in package.json which quite makes the zero-config idea, ideally we could remove it and still keep it as before but use some convention of folder as the entry points

Solution

To keep both typescript generated type files and dist are in the aligned structure, bunchee should find the entry files in top-level directories by the exported paths.

E.g., If there's ./lite export condition in exports field, bunchee should look up <rootDir>/lite.[extension] file as the entry file, extension can be one of the popular and supported file extentions like js, ts, jsx, tsx, mjs or cjs.

Then the generated dist file path should be specified from exports['./lite'], it can be any path in the dist folder such as ./dist/lite.js. The generated entry file types should be flattern into ./dist folder without nested directory. e.g.
Source file ./index.ts will be compiled to ./dist/index.js', which can now easily match ./dist/index.d.ts. This avoid the case that your source files are from ./srcfolder, then it still be deeply nested in the dist folder like./dist/src/index.d.ts`.

Unexpected token `implements`

Trying to build a TypeScript file. implements keyword seems not to be supported.

yarn run v1.22.10
$ bunchee src/index.ts -m --no-sourcemap
/home/ubuntu/repos/wedi/src/index.ts .ts true
 9: } from './typings';
10: 
11: export class DependencyCollection implements Disposable {
                                      ^
12:     public disposed: boolean = false;
Error: Unexpected token (Note that you need plugins to import files that are not JavaScript)
    at error (/home/ubuntu/repos/wedi/node_modules/rollup/dist/shared/node-entry.js:5400:30)
    at Module.error (/home/ubuntu/repos/wedi/node_modules/rollup/dist/shared/node-entry.js:9820:16)
    at tryParse (/home/ubuntu/repos/wedi/node_modules/rollup/dist/shared/node-entry.js:9713:23)
    at Module.setSource (/home/ubuntu/repos/wedi/node_modules/rollup/dist/shared/node-entry.js:10076:33)
    at /home/ubuntu/repos/wedi/node_modules/rollup/dist/shared/node-entry.js:12362:20
    at async Promise.all (index 0)
    at async Promise.all (index 0)
    at async Promise.all (index 0)
    at async Promise.all (index 0)

Upgrade to rollup 3

could not find a copy of typescript to link in bunchee

Tried to use bunchee in a TypeScript 4 project. Seems that bunchee doesn't support TypeScript 4 at the moment.

Image support

Hi! Thanks for great library.

Does bunchee have image support?

Polish error trace in watch mode

Instead of logging the full error object with properties like frame, loc, code, log the frame as trace first, then log other properties in a certain format, for better and easier viewing

Respect bin field in package.json if specified

Auto add shebang header if dist path matches the binary path specified in package.json bin field

Support iife format for CLI

iife format is not a standard output for organized modules like cjs / esm but will be useful for the case like building a polyfill script that can run directly in browser

Deno compatibility issue

How to make it Deno compatible?

Bundle types

https://github.com/Swatinem/rollup-plugin-dts is a nice option for bundling output types into 1 file

Esmodule mark is not enabled properly when main and module field are presented in the exports filed

useEsModuleMark = Boolean(tsCompilerOptions.esModuleInterop || exportPaths.main && exportPaths.module);

Since the tsCompilerOptions is not fully parsed (#147), it falls back to the 2nd condition. The exportPaths might not contain main and module field. It could be { '.': { main, module, export } } presented for exports condition format. This needs to be supported as well

Build cache needs to be consistent with git sha

using wildcards error

Does it support multiple entries using wildcards, for example

Use preserve shebang plugin instead of bin argument

learn from comments while contributing to tsdx project, shebang should be preserved since it's allowed in nodejs, but currently acorn version of rollup cannot perform on parsing this.

• bin path can be isolated from main / module path
• bin field could be an object mapping to few commands
• user can keep shebang in source code instead of manually adding it to output

Support exports sugar

• https://nodejs.org/api/packages.html#exports-sugar
• https://webpack.js.org/guides/package-exports

Output error or highlight the error when typescript compilation failed

When running into ts some issues with swr, bunchee exits successfully

Support Compiling and Bundling Typescript

Resolve jsx extension

Bug

Currently jsx syntaxes in .js ext file are available to use. but jsx extension is failed to resolve.

Expected

.jsx ext files should be resolved successfully by bundler

Respect emodule interop field in tsconfig

Replace the content

Customize to replace some code with new text, not limited to process.env but also open to other code replacement. Need some examples

Provide --env <env1,env2,...> as arg to pick the env you need to inline in the code

Class properties syntax support

regeneratorRuntime is not defined (`--target node`)

When I try to bundle a JavaScript library that uses async functions and then use that library, I get ReferenceError: regeneratorRuntime is not defined, even when using --target node.

I found that the issue is resolved by adding { target: { node: "16" } } to the options of babel-preset-o in createInputConfig in src/rollup-config.ts, since instead of the async/await keywords being transformed to use regeneratorRuntime, they are just passed through to the output as is. Though I'm not sure exactly what value node should be instead of "16". Also, perhaps esmodules: true should be also added to target like it was before? (see below)

bunchee/src/rollup-config.ts

Lines 60 to 63 in 9b67e95

	targets: {
	node: '4',
	esmodules: true,
	},

Babel target: transform all

current babel config targets on node 4.x syntaxes, still have some ES^ syntaxes that not been transformed, such as template literials

Support external from command line argument

Example

bunchee src/index.js -e react

Does "react-jsx" work?

This is a very cool tool, thanks for creating it! I was wondering about compiling React, is setting "jsx": "react-jsx" in tsconfig.json supposed to work? I'm getting the following error message when I try to compile a .tsx file:

Error: @rollup/plugin-typescript TS2686: 'React' refers to a UMD global, but the current file is a module. Consider adding an import instead.

Let me know if you need a repro.

Please support generator syntax

Hey bunchee maintainer! I am trying to use bunchee to compile my generator code but it just can't! Could you please add support for that feature? thank you!

Jobs timing log for multi entries build

Need some indicator or successful message to tell user it's finished

cli: support compile multiple sources to multiple dist

currently can only use bunchee with main and module fields in the package.json, bundle file to one dist

bunchee src/index.js

but sometimes we want to bundle multi src to multi dist

bunchee src/index.js -cjs -esm -d ./dist/ && bunchee src/react.js -d ./

# then I'll have

--
 |- dist
     |- index.cjs.js
     |- index.esm.js
|- react.cjs.js
|- react.esm.js

Typing: separate cli args extra meta info and orginal cli args

there're some parameters like exportCondition, we don't want it to be used since it's designed for carrying information during build. We could separate another typing for it

Watch mode for multiple entries

The watch mode ends quickly for multiple entries

Handle warning of rollup

Rollup warning when using bunchee:

implicitly using "default" export mode, which means for CommonJS output that its default export is assigned to "module.exports". For many tools, such CommonJS output. will not be interchangeable with the original ES module. If this is intended, explicitly set "output. exports" to either "auto" or "default", otherwise you might want to consider changing the signature of "..." to use named exports only.

Document the multi exports usage

Parse subpath exports from exports sugar

Today we need to add a package.json for a subpath folder if you want to build based on that working directory, for instance:

// pkg/a/package.json

{
   "name": "pkg-a",
   "exports": {}
}

In this way, you can build the assets based on the subpath pkg/a and generate output according to "exports" path in that package.json. Then we refer those outputs in the toplevel package.json for the corresponding subpath imports.
But this might confuse some tooling to understand the structure of the library better. Since node.js introduced the exports sugar, any subpath needs to provide a package.json just for getting assets output paths. bunchee should be able to auto detect it

Proposal

Introducing a new exports paths auto-detection feature for top level package.json.

Example

Assume we have a toplevel package foo with package.json which contains a subpath import foo/die

{
   "name": "foo",
   "exports": {
      "./die": {
          "import": "...",
          "require": "...",
          "types": "...",
      }
   }
}

Then you have your source folder of foo/die/ with entry file foo/die/index.js. In this case bunchee should read the output paths infomation from exports field if the current build working directory matches the any exports path

Doesn't honor tsconfig "target" property

Hi @huozhi,

I have set up bunchee according to the README, to bundle a TypeScript library that I'm working on. When I run it, the bundle is created without issues, however, it seems bunchee is not respecting the "target" property in tsconfig.json and instead defaults to using es5 as bundling target.

This is my tsconfig.json:

{
  "extends": "@tsconfig/node16-strictest/tsconfig.json",
  "compilerOptions": {
    "outDir": "build",
    "target": "ES6",
    "declaration": true,
    "noUncheckedIndexedAccess": false
  },
  "include": ["src/**/*.ts"],
  "exclude": ["node_modules"]
}

This is my bunchee config in the package.json:

{
  "type": "module",
  "main": "build/main.cjs",
  "types": "build/main.d.ts",
  "exports": {
    "require": "./build/main.cjs",
    "import": "./build/main.esm.js",
    "default": "./build/main.esm.js"
  },
  "scripts": {
    "build": "bunchee src/main.ts",
  },
  "devDependencies": {
    "bunchee": "^2.1.7",
  },
}

The code generated in the build/ directory contains some autogenerated polyfills which are not needed for ES6 code, which is an indication that the bundling is targeting ES5 instead of the ES6 target specified in the tsconfig.json. If I change the build script in package.json to bunchee --target es2015 src/main.ts, the generated bundle is different and doesn't contain all of those ES5 polyfills.

Watch mode seems not working

Repro Steps

1. git clone https://github.com/promer94/test-bunchee.git
2. yarn install && yarn watch
3. modify the src/index.ts, the output got rebuild but keep the same result

Additional Context

bunchee version 1.5.4
node version 12.18.3

Ability to override build target

It seems that ES5 is always the build output target, and will override the project tsconfig value:

bunchee/src/rollup-config.ts

Line 85 in 1a4ade8

target: "ES5",

Treate sub folder import as externals

if sub folder imports is from deps/peerDeps, treate as externals

import NextHead from 'next/head'

expected: not bundle sub imports like next/head into dist

Parsing the extended compiler options from tsconfig.json

Sor far bunchee is using thses ts API to access the tsconfig

tsconfigJSON = ts.readConfigFile(tsConfigPath, ts.sys.readFile).config;
tsCompilerOptions = ts.parseJsonConfigFileContent(tsconfigJSON, ts.sys, "./").options;

But turns out the extended ones in subpath are not accessible, it can only read the config without the inherited values from parnet config.

Improve hints when entry files are not detected

Polish error tracing format

Maximum call stack size exceeded on version >=2.0.2

Hi,

When I try to run xswr, a library built with bunchee version >=2.0.2 on a Next.js website, a "Maximum call stack exceeded" is thrown

Reproduction:

1. clone xswr: git clone https://github.com/hazae41/xswr && cd xswr
2. install dependencies: npm install
3. update bunchee: npm install --save-dev bunchee
4. build xswr: npm run build
5. link xswr: npm link
6. go to the test directory: cd test/next
7. install dependencies: npm install
8. remove xswr: npm remove @hazae41/xswr
9. link xswr: npm link @hazae41/xswr
10. run test with Next dev: npm run dev
11. go to http://localhost:3000
12. click some page and the error is thrown

This doesn't happen on 2.0.1, 2.0.0, 1.9.1

Thank you!

provide documents on the website

provide documents on the website,for example quick start and API infomation, options config infomation.

Don't transform class

Is there a way to prevent transforming classes?

Current behaviour:

Input:

import { LitElement, html } from 'lit';
import { customElement, property } from 'lit/decorators.js';

@customElement('custom-button')
export class Button extends LitElement {
  render() {
    return html`<button><slot /></button>`;
  }
}

Output:

var Button = /** @class */ function(_super) {
    __extends(Button, _super);
    function Button() {
        return _super !== null && _super.apply(this, arguments) || this;
    }
    Button.prototype.render = function() {
        return html(templateObject_1 || (templateObject_1 = __makeTemplateObject([
            "<button><slot /></button>"
        ], [
            "<button><slot /></button>"
        ])));
    };
    Button = __decorate([
        customElement('custom-button')
    ], Button);
    return Button;
}(LitElement);

Expected: preserve class
Thank you so much!