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)

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

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

The watch mode ends quickly for multiple entries

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

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

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

Leverage the target setting from tsconfig.json

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

Hi! Thanks for great library.

Does bunchee have image support?

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

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

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

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.

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

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

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

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

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

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

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.

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

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.

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

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!

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.

How to make it Deno compatible?

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!

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

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

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!

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

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

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)

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

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.

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

Does it support multiple entries using wildcards, for example

Example

bunchee src/index.js -e react

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.

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