Packaging for Multiple Targets

[zebulonj]

Howdy! Would you be open to a pull request that changes your build tooling to output distributable packages for multiple targets?

As is, it's problematic to include this module in a project targeted for the browser due to use of ES6+ features (arrow functions, spread,...). I think it's not uncommon for build tooling targeting the browser to exclude ./node_modules/ from transpilation (Babel). Of course... the user could always adjust their build, but.... Also, the module built here doesn't support tree shaking to reduce bundle size.

[zebulonj]

P.S. I'd propose a simple Rollup.js setup to generate three distributable bundles: umd, cjs, and es. Would be happy to apply that here via a pull request.

[staltz]

Hey zebulonj. The packages use ES6 which should be supported by all modern browsers without transpilation. You can see that this repo doesn't really have any other code than just an aggregation of each operator. It's quite simple. I'd like to keep -basics like that and if you want something different, should be easy to fork.

[zebulonj]

@staltz UglifyJS balks at the arrow functions and spread operators (out-of-box Webpack configuration). I see that you're minifying with Google's closure-compiler, so it's clearly possible without transpiling to ES5, but... for the masses (those not using the experimental harmony branch of UglifyJS).

[staltz]

I think UglifyJS is missing some opportunity here, because arrow functions have potential of minifying code even better. What about Uglify ES?

I mean, overall by now we should be using ES6 (ES2015) because it's already 3 years old

[zebulonj]

Agree with all that (uglify-es is just a temporary distribution of the harmony branch referenced above). Not to beat a dead horse (perhaps it’s time I push all of my dependencies through Babel with babel-presets-env targeted to appropriate browsers, rather than make any assumptions about those dependencies)... ES5/6 aside, the issue of tree-shaking remains. As is, I can’t shake this package to drop unused code from my final bundle.

[staltz]

Have you considered forking? :)

[zebulonj]

Always. I just like to try to avoid duplication and fragmentation whenever possible.

https://github.com/zebulonj/callbag-basics/tree/rollup-config

[staltz]

I understand, but callbags is a project built to be fragmented. It's a good thing, I've worked a lot on concentrated projects and they suffer from trying to be everything for everyone. Have you read https://staltz.com/open-source-without-maintainers.html ?

So let's try this: (1) fork whenever you think something could be better, (2) inform the original repo about the fork (3) update https://github.com/callbag/callbag wiki to mention your published fork, (4) let the strongest fork survive.

I'll also try to update the readme on -basics to mention other forks of basics. That helps against making people lost.