Bundle size optimisations? about biota

[gahabeen]

Hey,

I'm all for it 🙌
Size matters and it should be as small as possible. Biota is still new and clearly needs optimization.

Biota is build to be ran in any environment: client or server. So it should be able to fit in a CloudflareWorker too. Also, one nice thing about biota is that everything can be loaded in fauna (methods are individual User-Defined Functions too) so you - potentially - would only need to be calling fauna's endpoint for User-Defined Functions.

It'ld lovely of you to have a look and see what's possible for tree-shaking and size optimization in general.

Thanks!
P.S: Be careful, project isn't production ready just yet 😉

[vinaypuppal]

Hi, I did not get chance to look in to the existing config yet. I am planning to check it this weekend and I let you know.

[gahabeen]

I'll have a look at those. Seems promising :)

[gahabeen]

I'm splitting biota in quite a few libraries. Like @biota/schema, @biota/builder, @biota/factory, @biota/api, @biota/auth, etc.

I'm reorganizing in a composable way just so it becomes tiny (and even more readable).
Btw, I'm using microbundle as following your recommendations ;)

Just the looking at the number of characters, I reduced it by 8 times :)

I'll let you know once it's up!
(Disputing the @biota organization on npmjs right now, and still have some work before release anyway)

[gahabeen]

I've set up a webpack config instead (https://github.com/gahabeen/biota/blob/revamp/webpack.config.js).
It's still way too big because of the number of files and contents.

I think I'll write a second super-light library to use biota with the hosted code on fauna (in user-defined functions). It should be easy as well and weight nothing.

Let me know what you think @vinaypuppal.
I'll also need to refactor some code at some point anyway too.

[vinaypuppal]

Hi, @gahabeen Sorry for replying late was busy with work

1. Rather than using Webpack, we should use Rollup as this is library. A quote from this article

If your codebase is ES2015 modules and you’re making something to be used by other people, you probably want Rollup.

2. As mentioned in the article I would suggest changing tsconfig to

-    "target": "es5",
-    "lib": ["es2015", "dom"],
-    "module": "commonjs",
+    "target": "esnext",
+    "lib": ["esnext", "dom"],
+    "module": "ESNext",

So TS -> ESNext will be built and then we can use microbundle or our own rollup config to generate commonjs and umd bundle.

Note: As mentioned in the article we should mention the module filed in package.json which should point to ES Modules version of our lib, so bundlers used by our library users like Webpack can implement tree-shaking.

  "main": "dist/foo.js",           // output path for CommonJS/Node
  "module": "dist/foo.module.js",  // output path for JS Modules
  "unpkg": "dist/foo.umd.js",      // optional, for unpkg.com

I tried to integrate microbundle in the revamp branch but I am getting a lot of TS errors so I did not continue. Once you are done with the API changes lets experiment with microbundle or our own rollup config and see bundle size.

[vinaypuppal]

One more indicator for tree-shaking to work is we need to add is sideEffects field in package.json
More info about it here

[vinaypuppal]

Awesome!

Waiting for the release.