huozhi / bunchee Goto Github PK
View Code? Open in Web Editor NEWZero config bundler for ECMAScript and TypeScript packages
Home Page: https://npmjs.com/bunchee
Zero config bundler for ECMAScript and TypeScript packages
Home Page: https://npmjs.com/bunchee
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)
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)
Lines 60 to 63 in 9b67e95
bunchee default output to es5, since IE11 is not supported officially anymore, the default output should change to es6 or even higher
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
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
current babel config targets on node 4.x syntaxes, still have some ES^ syntaxes that not been transformed, such as template literials
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?
Auto add shebang header if dist path matches the binary path specified in package.json bin
field
provide documents on the website,for example quick start and API infomation, options config infomation.
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
Currently jsx syntaxes in .js
ext file are available to use. but jsx extension is failed to resolve.
.jsx
ext files should be resolved successfully by bundler
The watch mode ends quickly for multiple entries
Leverage the target
setting from tsconfig.json
bunchee src/index.js -e react
git clone https://github.com/promer94/test-bunchee.git
yarn install && yarn watch
src/index.ts
, the output got rebuild but keep the same resultbunchee version 1.5.4
node version 12.18.3
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,
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:
git clone https://github.com/hazae41/xswr && cd xswr
npm install
npm install --save-dev bunchee
npm run build
npm link
cd test/next
npm install
npm remove @hazae41/xswr
npm link @hazae41/xswr
npm run dev
This doesn't happen on 2.0.1, 2.0.0, 1.9.1
Thank you!
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.
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!
Need some indicator or successful message to tell user it's finished
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
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
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.
Tried to use bunchee in a TypeScript 4 project. Seems that bunchee doesn't support TypeScript 4 at the moment.
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.
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.
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:
Line 85 in 1a4ade8
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
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
pathbin
field could be an object mapping to few commandsuseEsModuleMark = 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
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.
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.
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
Introducing a new exports paths auto-detection feature for top level package.json.
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
How to make it Deno compatible?
Hi! Thanks for great library.
Does bunchee have image support?
with pnpm install, the path of regenerator might be not able to resolve, so we should always alias the one installed by bunchee
https://github.com/Swatinem/rollup-plugin-dts is a nice option for bundling output types into 1 file
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.